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SECTION  1.  SCOPE 


1.1  IDENTIFICATION 

This  document  contains  functional  requirements  for  two  application 
areas  and  their  external  interfaces  that  are  candidates  for  inclusion 
in  the  Army's  Tactical  Operations  System  (TOS)  at  division  level.  The 
Targeting  and  Maneuver  Applications  comprise  the  Division  Real-Time 
Applications  (DIVRAS)  developed  under  auspices  of  DARCOM  Battlefield 
Systems  Integration  staff  during  the  period  January  3  through  August  3, 
1977. 

1.2  FUNCTIONAL  SUMMARY 

The  DIVRAS  functional  requirements  are  specified  in  subsequent 
portions  of  this  document  in  terms  of  these  three  areas: 

External  Interfaces 
Targeting  Application 
Maneuver  Application 

Further  definition  of  software  functions  necessary  to  implement 
these  applications  is  provided  in  the  form  of  detailed  descriptions  of 
three  major  subsystems: 

Communications  Processing 
Data  Base  Management 
Graphics  Processing 

The  application  functions  provide  a  user  oriented  definition  of 
the  processes  necessary  to  accomplish  the  real-time  targeting  and 


maneuver  display  activities;  the  software  support  functions  offer 
representative  processing  capabilities  necessary  to  support  the 
applications. 

The  intent  of  this  document  is  to  define  the  real-time  targeting 
and  maneuver  applications  sufficiently  to  enable  decision  by  cognizant 
Army  agencies  on  whether  to  include  these  capabilities  in  the  TOS 
Required  Operational  Capability  (ROC)  scheduled  for  approval  in  third 
quarter  of.CY77,  and  make  preliminary  implementation  decisions  if 
necessary.  Since  these  represent  two  of  many  potential  applications 
to  be  included  in  TOS,  it  has  been  assumed  in  this  document  that  DIVRAS 
has  direct  access  to  TOS  ENSIT/FRENSIT  data.  The  precise  nature  of 
that  interface  has  not  been  detailed  herein,  in  order  to  allow  future 
Army  determination  of  an  implementation  of  that  interface  consistent 
with  tactical  doctrine. 

This  specification  focuses  on  the  two  specific  software  applica¬ 
tion  areas  and  their  external  interfaces.  Other  overall  hardware  and/or 
system  related  requirements  (e.g.,  quality  assurance  provisions,  diag¬ 
nostics,  personnel  and  training,  etc.)  are  not  part,  of  this  effort. 

In  this  approach  this  document  is  not  intended  to  restrict  or  pre-judge 
the  eventual  hardware  implementation  to  support  the  applications. 
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SECTION  2.  APPLICABLE  DOCUMENTS 


The  following  documents  were  utilized  as  references  in  the  develop¬ 
ment  of  particular  aspects  of  the  functional  requirements  described 
herein: 

TOS^  Staff  User  Manual  ,  January  1976 

Concept  of  Operation  and  Employment  for  the  Field  Artillery 
Equipped  With  TACFIRE 

Artillery  Target  Intelligence  -  Reference  Note,  July  1976 

Design  Description  Document  for  LP  Message  Skeletons 
Addendum  for  TACFIRE  -  23  April  1976 

Current  Operational  Concept  -  SOTAS 

Military  Systems  for  Tactical  Operations  (Reference  Handbook) 
MITRE,  April  1977  for  DARCOM/BSI 

Technical  Interface  Concept  for  Target  Acquisition  and 
Control  Systems  -  DARCOM/BSI 

U.  S.  Army  Field  Manual  #100-5  -  July  1976 

Intelligence  Preparation  of  the  Battlefield  -  TC30  Techniques 
of  Tactical  Intelligence  Analysis  -  March  1976  (Draft)  - 
USAICS,  Ft.  Huachuca 

Specification  for  Interactive  Graphic  Capability  for  ASSIST 
AN/GYQ-21 (V)  -  1  February  1977 

Division  Real  Time  Applications  Specification  (DIVRAS) 

Report  -  3  August  1977 
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SECTION  3.  REQUIREMENTS 


MAJOR  FUNCTIONS 


This  section  will  specify  software  functions  necessary  to  perform 
the  OIVRAS  Targeting  and  Maneuver  Applications.  Figure  3-1  illustrates 
how  the  functions  required  by  these  two  applications  are  allocated 
among  three  major  software  subsystems--Communi cations  Processing,  Data 
Base  Management,  and  Graphics  Processing.  Targeting  and  maneuver  data 
in  the  form  of  message  traffic  feeds  into  DIVRAS  via  the  Communications 
Processing  Subsystem.  Communications  control  and  initial  message 
processing  for  routing  purposes  is  accomplished  there  in  addition  to 
logging  and  data  buffering  before  transfer.  The  Data  Base  Management 
Subsystem  performs  furtner  data  validation,  formatting,  and  logical 
processing  before  entering  the  data  into  file,  forwarding  alert  messages 
to  the  targeting/maneuver  analyst  where  required.  It  further  handles 
all  analyst  interactions  with  the  data  base--queries ,  searches,  updates, 
outputs--providing  responses  directly  to  alphanumeric  terminals,  or 
through  the  Graphics  Processing  Subsystem  to  the  graphics  displays. 

The  Graphics  Processing  Subsystem  provides  functions  necessary  to 
generate  and  manage  data  presented  as  images,  providing  capabilities 
to  both  the  targeting  and  maneuver  analyst  to  graphically  portray 
real-time  data  in  a  geographic  perspective.  By  means  of  these  major 
functions,  real-time  targeting  and  maneuver  display  activities  can  be 
performed. 

Primary  DIVRAS  functions  (including  the  necessary  input  data  an  i 
resulting  outputs)  are  specified  in  Section  3.1  -  Detailed  Functional 
Requirements.  These  sections  describe  in  user-oriented  terms  the 
minimum  functions  essential  to  adequate  performance  of  the  two 
applications. 
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These  requirements  have  been  further  definitized  in  Section  3.2  - 
System  Support  Software  by  identifying  requirements  for  a  representative 
approach,  allocating  software  functions  across  the  three  major  soft¬ 
ware  subsystems,  and  describing  the  detailed  software  functions  within 
each  subsystem  necessary  to  fulfill  the  requirements  defined  in  Section 
3.1.  Recognizing  that  the  DIVRAS  functions  may  be  only  a  subset  of  the 
applications  required  for  Division  Command  and  Control,  the  allocation 
of  functions  across  software  subsystems  and  the  specific  lementation 
approaches  within  each  subsystem  are  intended  to  provide  further 
explanation/definitization  of  the  primary  requirements,  not  to  specify 
an  implementation  approach.  Any  approach  offering  at  least  equivalent 
function  and  meeting  the  requirements  defined  in  Section  3.1  will  be 
sufficient  for  the  DIVRAS  applications. 

EQUIPMENT  INTERFACES 

The  DIVRAS  software,  in  order  to  be  responsive  to  application 
requirements,  should  operate  on  a  general  purpose  hardware  processing 
configuration  which  will  permit  rapid  response  to  all  operational  and 
external  communication  functions  in  an  on-line  (foreground)  mode,  as 
well  as  permit  background  mode  task  initiation  and  execution.  The 
operational  functions  will  include  extensive  on-line  use  of  flexible 
data  base  management/communication  and  graphics  software.  Figure  3-2 
portrays  basic  hardware  system  capabilities  with  which  the  software 
must  interface. 

Figure  3-2  indicates  two  major  hardware  subsystems:  the  communica¬ 
tions  processing  subsystem  and  the  data  base  management/display  processing 
subsystem.  This  separation  is  desired  to  permit  maximum  evolution  and 
responsiveness  for  each  of  the  separate  parts  of  the  system.  With  this 
approach,  as  the  communication  protocols,  formats,  rates,  and  sensor 
ground  station  functional  tradeoffs  evolve,  it  is  intended  that  the 
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impact  to  the  DIVRAS  communication  processing  software  can  be  better 
contained  and  managed.  In  a  similar  manner,  as  the  DIVRAS  display  and 
data  control  applications  evolve,  they  can  likewise  be  managed  and 
contained.  The  data  base  management  and  the  graphics  display  are 
included  in  one  subsystem  because  of  their  inherently  integrated  nature. 
The  fundamental  output  of  the  data  management  system  software  is  display 
(both  alphanumeric  and  graphic)  of  the  qualified  information.  The  graphic 
and  alphanumeric  processing  software  presents  data  automatically  or 
initiated  by  an  operator  which  in  effect  represents  data  that  has  been 
logically  managed,  qualified,  and  processed  by  the  data  management 
software. 

The  data  management  and  display  subsystem  should  contain  appro¬ 
priate  hardware  and  supporting  software  to  accommodate  the  functions 
of  initial  data  base  and  program  loading  as  well  as  software  control 
table/data  base  maintenance  task  initiation. 

The  communication  processing  subsystem  should  contain  a  program 
load  device  (a  removable  media  with  an  off  line  preparation  mode,  such 
as  a  diskette  with  key  to  disk  capability  is  desirable)  and  an  alpha¬ 
numeric  display  terminal  to  support  the  functions  of  program  initiali¬ 
zation  and  communication  configuration  control. 

The  communications  processing  subsystem  performs  the  tasks  of: 

•  input  and  output  connuni cations  processing  to  the  external 
communication  interfaces 

•  separation  and  buffering  of  the  message  data  and  the  bulk 
message  detection  data  (the  former  supports  the  targeting 
application  while  both  support  the  maneuver  application) 
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•  system  log  management 


•  short  period  outage  continuity  (recovery  of  information 
preserved  on  the  system  log) 

The  data  base  management  and  display  processing  subsystem  performs 
the  tasks  of: 

•  message  to  data  base  conversion  processing  (including 
translation  and  inference) 

•  data  basing  for  the  targeting  and  maneuver  applications 

•  display  processing  (alphanumeric  as  well  as  integrated 
targeting  and  maneuver  graphics) 

•  interactive  terminal  support  (including  formatting  for 
interoperability) 

0  system  data  control,  error  monitoring  and  recovery. 

PROGRAM  INTERFACES 

In  the  absence  of  other  applications,  the  major  DIVRAS  program 
interface  will  be  with  the  operating  system  software  of  the  chosen 
implementation  approach. 

In  specifying  the  software  functions  described  herein,  and  in 
consonance  with  the  hardware  assumptions,  the  following  characteristics 
have  been  assumed  about  the  operating  system  that  will  support  DIVRAS: 


1.  It  will  be  capable  of  controlling  multiprogramming  operations 
--multiple  concurrent  tasks  on  both  on-line  (foreground)  and 
background  task  levels. 

2.  Access  methods  and  device  handling  operations  supporting  all 
required  devices  indicated  in  Figure  3-2  will  be  provided. 

3.  The  0/S  will  provide  full  development  support  (compilers, 
assemblers,  library  support)  plus  utilities  software. 
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3.1  DETAILED  FUNCTIONAL  REQUIREMENTS 


3.1.1  External  Interfaces 

3. 1.1.1  Interfaces 

The  DIVRAS  applications  shall  be  capable  of  supporting  interfaces 
to  the  generic  tactical  nodes  indicated  in  Figure  3. 1.1-1. 

These  applications  shall  support  direct  or  indirect  interface  to 
the  following  seven  sensor  data  sources: 

TACFIRE 

SOTAS 

TRAILBLAZER 
TEAM  PACK 
GUARDRAIL 
QUICKLOOK 
MAGI  I C  OV-1 

The  specific  input  and  output  message  types  and  message  rate  requirements 
for  these  interfaces  is  specified  in  the  following  paragraphs. 

3. 1.1.2  Inputs 

3.1. 1.2.1  Input  Messaqe  Types 

The  DIVRAS  applications  shall  support  processing  of  all  input 
message  types  indicated  in  Figure  3. 1.1-2  (specific  formats  are  indicated 
in  Appendix  I ) . 

The  DIVRAS  applications  shall  support  direct  processing  of  existing 
TACFIRE  formats  as  inputs  to  include  the  following: 
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AVIATION 


FIGURE  3. 1.1-1.  DIVRAS  PRIMARY  EXTERNAL  OUTPUT  MESSAGE  INTERFACES 
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ATI/T6R 

ATI/Query 

ATI/MFR 

FM/RFAF 

PTA 

The  DIVRAS  applications  shall  support  direct  processing  of  existing 

2 

TOS  formats  as  inputs,  to  include  the  following: 

ESD 

EUS 

UTO 

UTF 

UTD 

UAA 

The  DIVRAS  applications  shall  support  direct  processing  of  input 
messages  from  the  SOTAS  Ground  Station,  Division  SIGINT  Sources,  and 
the  Corps  to  accommodate  the  following: 

Response  to  queries 

Analyzed  target  intelligence  data 

Specified  target  or  track  updates 

The  DIVRAS  applications  shall  support  direct  processing  of  time- 
grouped  detections  of  Shooter,  Mover,  and  Emitter  data  from  the 
following  sources: 

TACFIRE 

Division  SIGINT  Sources 
Corps  SIGINT  Sources 


3.1. 1.2.2  Input  Message  Rates 

The  DIVRAS  applications  shall  support  direct  processing  of  analyzed 


Target  Intelligence  Messaqe 

types  identified 

in  paraqraph  3.1. 1.2.1  in 

accordance  with  the  minimum 

rates  specified 

be!  ow : 

Source  Interface 

Tarqet 

Category 

Peak  Hour  Messages 

TACFIRE 

Mover 

21 

TACFIRE 

Shooter 

153 

SOTAS 

Mover 

66 

Division  ELINT 
(TEAM  PACK) 

Radar 

7 

♦Division  COMINT 
(TRAILBLAZER) 

40 

Corps  ELINT 
(QUICKLOOK) 

Radar 

15 

♦Corps  COMINT 
(GUARDRAIL) 

47 

Corps  A1 1  Source 

150 

The  DIVRAS  applications 

shall  support  direct  processing  of  time- 

group  detections  of  shooters 

,  movers,  and  emitters  at  a  maximum  of  five 

minute  intervals.  The  capability  shall  be  provided  to  acconmodate  at 

each  five  minute  interval  the  minimum  number 

of  detection  locations  as 

specified  below: 

Source  Interface 

Target 

Category 

Peak  Load  Detections 
(5  Minutes) 

TACFIRE 

Mover 

11 

TACFIRE 

Shooter 

30 

Division  COMINT 
(TRAILBLAZER) 

Emi tters 

83 

Corps  COMINT 

Emi tters 

55 

(GUARDRAIL) 

★ 


These  input  messages  will  be  provided  via  the  Division  or  Corps  All 
Source  Interface 


(More  detailed  data  and  rationale  for  data  rates  is  provided  in 
Appendix  IV.) 


3. 1.1.3  Interface  Processing 

In  the  process  of  receiving  and  outputting  data  from  the  specified 
interfaces  the  DIVRAS  applications  shall  provide  two  general  purpose 
functions  to  accommodate  the  multiple  interfaces  as  well  as  the  analyst 
who  utilizes  the  applications.  These  functions  are  identified  as 
Translation  and  Inference. 

3. 1.1. 3.1  Translation 

The  DIVRAS  applications  shall  be  capable  of  translating  all  data 
elements  in  all  input  messages  into  a  common  internal  set  of  data  elements 
utilized  for  internal  application  processing. 

The  DIVRAS  applications  shall  be  capable  of  translating  an  analyst 
oriented  set  of  English  language  terms  into  a  common  set  of  data 
elements  utilized  for  internal  application  processing. 

The  DIVRAS  applications  shall  be  capable  of  translating  all  common 
internal  data  elements  into  the  corresponding  data  elements  used  in  the 
external  interface  output  messages. 

The  DIVRAS  applications  shall  be  capable  of  translating  all  common 
internal  data  elements  into  the  corresponding  analyst-oriented  set  of 
English  language  terms. 

The  translation  table  identifying  the  correspondence  between 
internal  data  elements  and  external  interface  date  elements  or  English 
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language  terms  shall  be  changeable  and  can  be  added  to  by  background 
processing  methods  up  to  a  maximum  of  2000  items. 

3. 1.1. 3.2  Inference 

The  DIVRAS  applications  shall  be  capable  of  inferring  from  logical 
processing  of  multiple  fields  in  any  of  the  input  messages  the  following 
internal  data  fields  when  such  data  is  not  provided  by  the  input  message: 

Target  Category  Method  of  Detection 

Target  Worth  Target  Permanence 

Location  Error 

The  DIVRAS  applications  shall  update  the  processed  and  data  based 
version  of  the  input  message  with  the  inferred  values. 

The  logical  combination  of  data  elements  utilized  to  determine 
inferred  values  shall  be  changeable  by  table  entry  change  using  back¬ 
ground  processing  methods. 

(More  detailed  examples  of  Inference  tables  are  provided  in 
Appendix  III.) 

3. 1.1.4  Outputs 

The  DIVRAS  applications  shall  support  generation  and  formatting  of 
all  output  message  type  indicated  in  Figure  3. 1.1-2  (specific  formats  are 
indicated  in  Appendix  I). 
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The  DIVRAS  applications  shall  support  direct  generation  and 
formatting  of  existing  TACFIRE  formats,  as  outputs,  to  include  the 
following: 

FM  (or  ATI/CDR) 

FM/PTA 
ATI/SRI 
ATI /Query 
SPRT  or  FSE 

The  DIVRAS  applications  shall  support  direct  generation  and 
formatting  of  output  messages  to  the  SOTAS  Ground  Station,  Division 
S IGINT  Sources,  and  to  Corps  to  accommodate  the  following: 

Standing  Request  for  Information 
Provide  Command  Guidance 
Query  the  External  Interface 

The  automated  release  of  the  output  message  shall  be  subject  to 
the  targeting  or  maneuver  analyst  concurrence  through  action  at  an 
interactive  terminal. 
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3.1.2  Targeting  Application 

The  objective  of  the  targeting  application  within  the  Division 
Real  Time  Application  System  (DIVRAS)  is  to  enhance  the  DTOC  process 
of  weapon  assignment  against  real  time  targets  of  worth  in  a  dynamic 
battle  environment  within  the  division  echelon. 

Figure  3. 1.2-1  presents  an  overview  of  the  targeting  application 
in  terms  of  basic  inputs,  sub-functions  (processes),  and  outputs.  The 
targeting  application  shall  accept  real  time  targeting  messages  from 
four  major  interfacing  nodes  as  well  as  enemy  activity,  enemy  unit  and 
friendly  unit  data  from  the  Tactical  Operations  System  (TOS)  ENSIT,  and 
FRENSIT  Data  Bases. 

The  targeting  application  shall  also  accept  as  input  the  on-line 
user  commands,  changeable  parameter  controls  and  queries  necessary  to 
control  the  total  targeting  application  as  well  as  respond  to  the 
analyst  information  needs,  both  from  the  local  DIVRAS  data  base  as  well 
as  interoperating  with  the  other  interfacing  systems  in  such  a  fashion 
as  to  permit  query,  standing  requests  for  information,  target  data 
routing  and  dissemination. 

All  target  message  data,  as  defined  in  paragraph  3.1.1,  shall 
undergo  translation  and  inference  processing  and  shall  update  the 
DIVRAS  targeting  and  maneuver  application  data  base.  The  data  base 
update  function,  including  the  translation  and  inference  capabilities, 
are  defined  in  paragraph  3.2.2. 
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3. 1.2.1  Target  of  Interest  Processing  Subfunction 


Figure  3. 1.2-2  indicates  the  inputs,  processes  and  outputs  of  tne 
target  of  interest  processing  subfunction. 

This  subfunction  shall  automatically  process  all  incoming  target 
or  enemy  activity  message  data  (which  has  not  been  already  directly 
reported  by  the  sensor  system  to  a  weapon  system)  to  determine  if  the 
target  or  activity  is  of  current  interest  to  the  targeting  analyst. 

Current  interest  shall  be  defined  by  a  targeting  filter 
table. 

The  determination  of  current  interest  shall  be  made  on 
the  incoming  target  or  activity  message  only  after  trans¬ 
lation  and  inference  processing  have  occurred. 

If  the  target  is  of  interest,  the  correlation,  association  and 
assignment  processing  steps  shall  automatically  occur;  display  presen¬ 
tations  shall  automatically  be  prepared  and  the  analyst  shall  be  noti¬ 
fied  of  a  new  target  of  interest  entry  into  the  target  of  interest  work 
queue  without  disruption  to  his  current  work  activity. 

If  the  target  or  activity  is  not  of  interest,  no  further  target  of 
interest  processing  steps  shall  occur. 

Whether  or  not  the  target  or  activity  is  determined  to  be  of 
interest,  the  input  message  shall  update  the  targeting/maneuver  data 
base  after  translation  and  inference  processing  have  occurred  (see 

paragraph  3.2.2). 


TARGET  OF  INTEREST.  PROCESSING 


The  time  to  process  a  target  of  interest,  from  the  time  processing 
is  initiated  on  that  target  until  the  alert  line  to  the  analyst  is  dis¬ 
played,  shall  not  exceed  15  seconds  on  the  average  and  shall  not  exceed 
30  seconds  for  80  percent  of  all  targets  which  result  in  a  target  of 
interest  display.  This  time  shall  exclude  any  cormiunications  processing 
and  queuing. 

In  order  to  implement  the  algorithms  stated  below,  the  system  snail 
be  capable  of  supporting  logical  combination  on  any  storable  data  element 
in  any  boolean  or  arithmetic  manner  (and's,  or's,  between  limits  greater.' 
less  than  and  literal  search). 

3. 1.2. 1.1  Filter  Algorithm 

The  target  filtering  process  shall  permit  the  system  to  automati¬ 
cally  determine  whether  further  target  of  interest  processing  on  an 
incoming  message  is  required. 

The  target  filtering  algorithm  shall  be  specified  by  a  table  wnose 
rows  are  all  of  the  possible  targeting  or  enemy  activity  message  types 
and  whose  columns  are  selected  message  data  elements. 

The  column  elements  of  any  row  shall  be  logically  combinable 
to  form  a  logical  equation  for  that  row  which  shall  then  ee 
used  as  the  filter  for  determining  interest  for  that  row 
(message  type). 

Figure  3. 1.2-3  indicates  the  filter  algorithm. 

The  actual  criteria  values  ( X 1  s )  shall  be  changeable  by 
either  analyst  mode  control  (see  paragraph  3. 1.2. 4)  or  a 
table  maintenance  processing  routine  initiated  as  a  bad  - 
ground  task  to  the  on-line  system. 

I 
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FIGURE  3. 1.2-3.  FILTER  ALGORITHM 


The  system  shall  additionally  provide  the  targeting  analyst 
the  ability  to  change  the  area  definitions  on-line. 


3. 1.2. 1.2  Correlation  Algorithm 

For  each  incoming  target  or  activity  report  which  passes  tne  filter 
algorithm,  the  system  shall  automatically  perform  correlation  processing 
to  assess  the  key  attributes  of  target  worth,  target  accuracy  (location 
error)  and  target  permanence  and  attempt  to  automatically  make  a  fire 
mission  recommendation. 

Correlation  processing  shall  be  based  upon: 

the  incoming  message  data  (as  translated  and  inferred), 
other  messages  already  in  the  targeting  data  base, 
selected  rules  of  engagement  currently  reflected  within 
the  system. 

Figure  3. 1.2-4  indicates  the  correlation  algorithm  in  matrix  form. 
It  shall  be  possible  to  add/delete  correlation  situations  (rows)  to 
this  table  in  an  off-line  manner  to  adapt  it  to  a  specific  tactical 
scenario,  echelon,  or  target  acquisition  sensor  mix. 

The  specific  values  such  as  specified  number  of  meters,  or 
specified  worth  values,  shall  be  changeable  by  either  analyst 
mode  control  (see  paragraph  3. 1.2. 4)  or  a  table  raintenance 
processing  routine  initiated  as  a  background  task  to  the 
on-line  system. 

The  specified  named  polygon  definitions  in  the  table  shall  be 
taken  from  the  named  polygon  definitions  contained  in  trie 
control  (geometry)  record  portion  of  the  targeting  data  base 
and  as  such  shall  be  changeable  on-line. 
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3. 1.2. 1.3  Association  Algorithm 


Regardless  of  the  results  of  the  correlation  processing  step,  the 
association  algorithm  shall  additionally  relate  the  incoming  target  or 
activity  message  with  previously  reported  target  or  activity  message 
data  contained  in  the  targeting  data  base. 

Based  upon  the  incoming  message  type  and  inferred  target  category, 
the  data  base  shall  be  searched  within  specified  distance  and  time 
constraints  for  specific  message  type  and  target  category  pairs. 

The  specified  distance  and  time  constraint  shall  be 
selected  based  upon  the  incoming  message  type  and 
target  category. 

Figure  3. 1.2-5  indicates  the  association  algorithm  in  matrix  form. 
There  shall  be  a  row  entry  provided  for  each  possible  message  type. 

3. 1.2. 1.4  Assignment  Algorithm 

The  assignment  algorithm,  regardless  of  the  results  of  either  the 
correlation  or  association  processing  steps  above,  shall  automatically 
make  an  assignment  recommendation  for  the  incoming  target  based  upon 
the  commander's  current  rules  of  engagement  reflected  within  the  system 
in  the  form  of  the  assignment  algorithm  table. 

The  assignment  step  shall  identify  whether  the  incoming  target 
falls  within  geographic  areas  addressably  by  friendly  artillery, 
tactical  air  support,  or  attack  helicopter. 

The  assignment  recommendation  shall  take  into  account  dynamic 
fire  control/coordination  areas  established  by  the  commander  or  his 
staff,  the  areas  addressable  by  friendly  weapon  delivery  means,  the 
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category,  worth,  accuracy  (location  error)  and  permanence  of  the 
incoming  target  (after  translation  and  inference  processing)  as  well 
as  whether  the  incoming  target  is  indicated  as  confirmed. 

In  those  cases  where  the  incoming  target  fails  to  meet  one  of 
the  assignment  criteria,  the  system  will  indicate  "no  assignment"  as 
the  recommended  assignment  (while  still  indicating  the  friendly  weapon 
delivery  means,  if  any,  which  can  address  the  incoming  target  location). 

Figure  3. 1.2-6  represents  the  assignment  algorithm  table  in  matrix 
form.  The  rows  indicate  any  of  the  possible  regions  (areas)  into  which 
the  target  could  fall.  The  first  three  regions  override  (in  respective 
order)  all  of  the  other  regions  and  result  in  the  assignment  at  the 
extreme  right  regardless  of  other  parameters. 

In  situations  where  more  than  one  weapon  asset  can  strike  the 
target,  the  assignment  shall  be  based  on  target  parameters  in  such  a 
manner  that  artillery  is  given  preference  providing  the  accuracy  is 
less  than  a  specified  number  of  meters  and  the  permanence  is  greater 
than  a  specified  number  of  minutes. 

Failing  this,  the  target  shall  be  assigned  to  either  tactical 
air  or  attack  helicopter  depending  upon  target  category  and 
worth  and  confirmation  status 

Failing  this,  a  "no  assignment"  recommendation  is  indicated. 

The  defined  areas  in  the  assignment  table  shall  be  taken  from  the 
named  polygon  definitions  contained  in  the  control  (geometry)  record 
portion  of  the  targeting  data  base  and  as  such  shall  be  changeable 
on  line. 
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FIGURE  3. 1.2-6.  ASSIGNMENT  ALGORITHM 


FIGURE  3. 1.2-6.  ASSIGNMENT  ALGORITHM  (SHEET  2  OF  2) 


The  area  of  a  specific  category  such  as  "division  no  fire  area" 
or  "helicoper  strike  area"  shall  not  be  limited  to  one  polygon  defini¬ 
tion  but  may  in  fact  be  multiple  disjoint  or  overlapping  polygons. 

Area  definitions  of  different  assignment  categories  may  be  either 
disjoint  or  overlapping. 

Specified  parameter  values,  other  than  area  definitions,  within 
the  assignment  table  shall  be  changeable  by  either  analyst  mode  control 
or  a  table  maintenance  processing  routine  initiated  as  a  background 
task  to  the  on-line  system. 

3. 1.2. 1.5  Display  Presentation 

The  results  of  target  of  interest  processing  shall  be  reported  in 
two  display  forms,  one  alphanumeric  and  one  graphic. 

Alphanumeric 

The  alphanumeric  display  shall  be  a  report  formatted  into  the 
five  major  information  segments  indicated  on  Figure  3. 1.2-7. 

When  more  related  targets,  than  the  five  indicated,  result 
from  the  correlation  and  association  steps,  a  multiple  page 
format  will  be  used. 

The  display  shall  be  capable  of  presenting  24  lines  by  80  charac¬ 
ters  of  information. 

The  bottom  line  of  the  display  shall  be  reserved  as  an  alert  line 
for  the  targeting  analyst. 
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TARGET  DATA  PRESENTATION 


TARGET: 

xxxxxxxxxxxxxxx 

AGENCY: 

xxxxxxxx 

LOCATION: 

xxxxxxxx 

TIME  : 

XXX  xxxx 

© 

© 

© 

© 

RELATEO  TARGETS: 

QUANTITY: 

M£ THOU: 

LOCATION. 

TIME: 

REFER!  NIL 

XXXXXXXXXXXXXXXXXXXX 

XXXXX 

XXX  'XXXX 

XXXXXXXX 

XXXXXXXX 

XXXXXX 

••••  x - X 

X - X 

X' —  X 

x -  X 

X'  X 

x - X 

X - X 

X--  X 

X  X 

X  X 

X  x 

X  X 

X - X 

X - X 

X" - X 

X - X 

x - X 

X  X 

XXXXXXXXXXXXXXXXXXXX 

XXXXX 

xxxxxxxx 

xxxxxxxx 

xxxxxxxx 

XAXXXX 

© 

© 

© 

© 

© 

© 

***«  FIRE  MISSION  RECOWTENDEU 

•  ••ft 

•••ft  •••• 

FIRE  MISSION 

RECOWiENUED 

ASSIGNMENT: 

TARGET  WITHIN  ARTY  ZONE: 

HELO  ZONE:  TACAIR  ZONE: 

XXXXXXXXXXXXXXXXXXXX 

XXX 

XXX 

XXX 

© 

© 

© 

© 

TARGET  MESSAGE:  XXXX 

SUBJECT:  XXXXXXXXXXXXXXXXXXXX 

CHARS : 

XXXXXXXXXXXXXXXXXXXX  LOCATION: 

xxxxxxxx 

QTY :  XXXXX  UIR:  XXX  VEL: 

XXX  PERM 

XXXXX  EOCIRR:  XXXX  T 1  ML 

xxxxxxxx 

TAR  i  NO:  XXXXXX 

agency,  mmim 

MITHOJ*  XXXXXXXXXXXXXXXXXXXX 

REMARKS:  XXXXXmmXXXXKmXXXXXX«XXXXXmXXUXXX>X*YXmXXXXXXXXXXXI(XXXXXXX;iimxmXI«X>X 

XXXXIXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXUXXXXXX 


LEGEND: 

G)  Incoming 
Q)  Incoming 
Q  Incoming 
Q)  Incoming 


Target  Message  Target  Category  Field 
Target  Message  Reporting  Agency 
Target  Message  Location 
Target  Message  Event  Time 


Information  items  5  through  10  apply  to  related  target 
observatitns  retrieved  from  the  data  base  In  accordant" 
with  the  correlation  and  association  roles.  Hits  in  Me 
data  base  corresponding  to  the  former  are  asterisked  a  id 
cause  the  system  fire  mission  recommended  line  to  be 
displayed.  The  time  field  can  be  used  as  the  sort  order. 


G> 

G 

G 


The  Subject  *1e1d  of  the  data  base  record 
The  quantity  field  of  the  data  base  record 
The  method  of  detection  of  the  data  base  record 
The  target  location  of  the  data  base  record 
The  event  time  of  the  data  base  record 

The  first  6  characters  of  the  record’s  data  bast- 
10 


^j)  The  reconmcnded  assignment  fro"  Me 

assignment  rules  (right  hand  column  of 
Figure  3.2. 1-6) 

(lj?)  States  (Yes  or  No)  whether  Incming 

target  location  is  within  at  last  one 
friendly  artillery  unit  zone  o'  fire 

(H)  States  (Yes  or  Mo)  whether  Incoming 

target  location  is  within  helo  strike  area 

States  yes  or  no  whether  intom-ng  target 
location  is  within  TACAIR  strUc  area 

(fs)  A  synopsis  of  the  incominq  target  message 
containing  the  fields  indicated 


FIGURE  3. 1.2-7.  TARGET  PRESENTATION  SUftiARY  DISPLAY  (ALPHANUMERIC) 
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When  the  target  of  interest  summary  display  (alphanumeric)  has 
been  processed  it  shall  be  entered  into  the  targeting  analyst's  target 
of  interest  work  queue  and  the  system  shall  automatically  display  an 
alert  line  message  to  the  targeting  analyst  in  a  manner  which  does  not 
disrupt  the  remainder  of  his  display  work  screen. 

All  data  fields  presented  in  the  target  of  interest  summary  shall 
use  analyst  terminology  consistent  with  the  translation  subfunction 
described  in  paragraph  3.2.2. 

Graphic 

The  principle  graphic  display  for  outputting  the  results  of  the 
target  of  interest  processing  shall  consist  of  a  colorgraphic  display 
containing  the  following: 

digitized  map  background  data 

control  boundaries  or  indicators  such  as  the  FEBA 

grid  tick  marks 

fire  control  areas 

maneuver  unit  zones  of  responsibility  near  the  FEBA 
target  of  interest  clusters  which  have  not  yet  been 
acted  upon. 

Each  incoming  target  of  interest  cluster  shall  be  added  automati¬ 
cally  (without  analyst  call  up)  to  the  graphic  display  in  blinking  mode. 

The  cluster  is  defined  as  the  incoming  target  and  the 
related  targets  retrieved  in  the  correlation  and  associ¬ 
ation  process  (in  some  cases  there  will  only  be  the  incoming 
target) . 


The  incoming  cluste-  shall  blink  on  the  graphic  side  from  the  time 
the  processed  incoming  target  cluster  has  been  placed  in  the  target  of 
interest  work  queue  until  such  time  as  the  analyst  has  retrieved  that 
cluster  from  the  work  queue  and  hence  caused  the  alphanumeric  display 
of  that  target  of  interest  summary. 

From  that  point,  the  target  cluster  shall  remain  on  the  graphic 
in  non-blinking  mode  until  such  time  as  the  analyst  takes  some  action 
on  that  target  such  as  assigning  it  as  a  fire  mission  or  reporting  it 
as  a  target  to  an  operational  node,  such  as  a  brigade  or  TACFIRE  or 
deleting  it  from  the  graphic  presentation. 

Graphic  Symbol/Color  Assignment 

Each  target  in  the  cluster  shall  be  assigned  a  symbol  from  a 
repertoire  of  up  to  256  displayable  symbols  which  shall  include  standard 
alphanumeric  and  control  characters  plus  application  tailorable  symbols 
(see  paragraph  3.1 .3.3). 

The  symbol  assignment  shall  be  based  on  the  reported  or  inferred 
subject  data  field  for  targets  or  enemy  activity  records  and  on  the 
enemy  or  friendly  unit  type  field  for  enemy  or  friendly  unit  records. 

It  is  desired,  although  not  required,  that  the  graphic 
display  be  capable  of  presenting  up  to  seven  different 
colors  which  will  be  assigned  as  indicated  in  Figure  3. 1.2-8. 

3. 1.2. 1.6  Operator  Graphic  Manipulation 

From  the  targeting  analyst  terminal  the  operator  shall  be  capable 
of  interacting  with  the  target  of  interest  subfunction  to  perform  graphic 
manipulations  with  both  scenes  and  symbols.  In  addition,  the  operator 
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shall  be  capable  of  interacting  with  certain  of  the  maneuver-oriented 
graphics  functions  as  described  in  Section  3.1.3.  Both  of  these 
requirements  are  described  below. 

Scene  Manipulation 

The  operator  shall  be  able  to  call,  superimpose,  or  delete  in  any 
combination  the  following  set  of  graphics  scenes: 

Target  Of  Interest  Clusters 

Adjunct  Overlays 

Unit  Situation  Display 

Simp 1 i f i eH  Commander's  (Threat)  Display 

Map  Backgrounds 

The  operator  shall  be  able  to  expand  or  contract  any  scene  or  super¬ 
imposition  of  scenes  that  are  being  currently  displayed  in  accordance  with 
the  expansion  requirements  of  paragraph  3. 1.3. 4. 2. 

The  expansion  or  contraction  shall  occur  around  a  center  point 
designated  on  the  display  by  means  of  interactive  device,  such 
as  cursor  or  light  pen. 

Symbol  Manipulation 

The  operator  shall  be  able  to  position,  display,  or  delete  any 
alphanumeric  or  target  symbol  from  the  target  of  interest  cluster  display. 

General  Graphic  Manipulation  Capabi 1 i ties 

The  operator  shall  be  able  to  interactively  draw  through  straight 
line  segments  the  outlines  of  tactical  areas  of  interest. 
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The  operator  shall  be  able  to  transfer  the  end  point  coordinates 
of  all  outlined  tactical  area  of  interest  to  the  system  data  along  with 
a  label  for  future  reference. 

The  operator  shall  be  able  to  annotate  using  alphanumeric  charac¬ 
ters  at  any  point  on  the  screen  which  is  designated  by  the  cursor  (or 
light  pen). 

The  operator  shall  be  able  to  identify  any  symbol  on  the  display 
interactively  and  retrieve  through  data  base  query  any  information  stored 
about  that  symbol . 

The  operator  shall  be  able  to  obtain  interactively  cursor  (or  light 
pen)  readout  in  MGR  coordinates  of  any  point  on  the  graphic  display. 

The  operator  shall  be  able  to  obtain  interactively  straight  line 
distances  in  meters  between  two  designated  points  on  the  graphic  display. 

3. 1.2. 2  Monitored  Area  Processing  Subfunction 

Figure  3. 1.2-9  indicates  the  inputs,  processes  and  outputs  of  the 
monitored  area  processing  subfunction.  This  subfunction  shall  auto¬ 
matically  process  all  incoming  target  or  enemy  activity  message  data 
(including  that  which  has  already  been  directly  reported  by  a  sensor 
system  to  a  weapon  system)  to  determine  if  a  threshold  value  has  been 
exceeded  in  any  area  being  monitored  as  described  below. 

The  performance  times  stated  in  paragraph  3. 2. 1.1  are 
intended  to  include  the  additive  impact  of  monitored  area 
processing  on  each  incoming  target  message  as  stated  herein. 
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The  targeting  analyst  shall  be  able  to  identify  a*  list  of**areas** 
to  be  monitored. 

For  each  area  to  be  monitored,  the  targeting  analyst  shall  be 
able  to  identify  a  monitored  area  parameter  matrix  (Figure  3.1.2-10) 
which  will  state  the  analyst's  thresholds  for  that  area. 

The  parameters  within  each  area  parameter  matrix  shall  be 
independent  of  any  other  area  parameter  matrix. 

The  rows  of  the  parameter  matrix  shall  be  any  set  of  eleven 
inferrable  target  categories. 

For  each  row,  independently  of  any  other  row,  it  shall  be  possible 
to  establish 

the  sliding  time  window  for  threshold  monitoring  within  that 
category 

threshold  values  for  the  number  of  reports  (within  that 
category  within  that  sliding  time  window),  and 

quantity  field  accumulation  for  all  reports  received  in  that 
category  within  that  time  window. 

The  sliding  time  window  shall  be  interpreted  as  the 
current  system  time  less  the  specified  number  of  minutes 
(e.g.,  a  specified  time  of  30  minutes  would  only  include 
in  the  threshold  check,  data  base  and  incoming  reports 
whose  event  times  were  less  than  30  minutes  old). 
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■<:^!.ever  the  system  detects  a  threshold  exceeded  in  any  monitors 
.,r>  j  ,  '  shall  prepare  a  monitors  '  area  summary  report  (as  indicated  ’> 

.  ;..4i  >.i  „-ll)  and  enter  it  into  the  targeting  analyst's  monitored 

area  wort  queue  as  well  as  notify  the  analyst  that  a  monitored  area 
r..r..  been  exceeded  by  means  of  an  alert  line  message  displayed  on  tne 
uottorn  line  of  the  analyst's  alphanumeric  display. 

The  displaying  of  the  alert  time  shall  not  be  disruptive 
to  the  current  work  activity  of  the  analyst. 

ween  the  analyst  draws  the  report  out  of  the  queue  a  correspond'.., 
iraphic  shall  be  displayed. 

Tiiis  call  up  graphic  will  only  contain  all  target  reports 
(within  the  respective  sliding  time  windows)  of  all  monitor  ? 
categories  in  the  monitored  area. 

i.l.d.d.Z  Parameter  Change 

The  Monitored  Area  Subfunction  shall  permit  the  operator  to 
os  tab  1 i sh/change/delete 

the  monitored  area  definitions 

the  target  categories  to  be  monitored  in  each  area 
the  sliding  time  values  for  each  category,  and 
the  threshold  values  for  quantity  accumulation  and  number 
of  reports  for  each  category,  in  a  convenient  on-line  manner. 

Additionally,  table  maintenance  initiated  in  background  mode  shai 
also  be  possible. 
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3. 1.2. 3  Mission  Request  Processing  Dissemination  Subfunction 

Figure  3.1.2-12  indicates  the  inputs,  processes  and  outputs  of 
the  mission  request  processing  dissemination  subfunction. 

Under  targeting  analyst  initiation,  this  subfunction  shall  auto¬ 
matically  process  the  data  of  a  specific  target  or  target  cluster  into 
either  a  mission  request,  a  target  report,  or  a  set  of  target  reports 
and  transmit  them  to  the  indicated  recipient  node  or  element. 

The  target  analyst  shall  be  able  to  indicate  to  the  system  what 
target  or  target  cluster  he  wishes  to  involve  in  this  processing  stage. 

In  the  case  of  target  clusters  in  the  target  of  interest  work 
queue,  a  simple  graphic  cursor,  light  pen  or  menu  selection 
technique  shall  be  used. 

In  the  case  of  ad  hoc  target  processing  the  analyst  shall  be 
able  to  indicate  the  targets  in  the  data  base  he  wants  to 
irfvolve  in  this  processing  stage  by  inputting  appropriate 
target  reference  identification. 

The  targeting  analyst  shall  be  able  to  establish  queries  or  stand¬ 
ing  requests  for  information  (SRI)  with  the  interfacing  systems. 

The  analyst  shall  have  the  full  modifiable  prcstored  query  feature 
support  of  the  data  base  management/communication  system  (paragraph 
3.2.2)  in  preparing  queries  or  SRI's  to  his  own  data  base  well  as  to 
those  of  interfacing  systems. 

For  queries  or  SSI's  to  interfacing  systems,  the  subfunction 
will  automatically  insert  and  monitor  for  a  linkage  number 
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such  that  when  the  response  is  received  it  can  be  coupled 
with  the  initiating  a'-f-ry  and  plac'd  in  the  analyst's  exter¬ 
nal  query/SRI  respons  .  work  queue. 

A  non-di srupti ve  alert  line  will  indicate  to  the  analyst  that 
a  response  has  been  received. 

The  analyst  shall  be  able  to  draw  the  response  out  of  the  queue 
and  display  it  together  with  the  query  or  SRI. 

Graphic  presentation  of  target  query/SRI  nusults  shall  also  to- 
initiated  where  applicable. 

The  DIVRAS  software  system  shall  perform  required  translation  and 
formatting  both  of  the  quer  RI  as  well  as  the  responses.  The  target¬ 
ing  analyst  shall  not  require  knowledge  of  the  interfacing  node  query/ 
SRI  formats. 

3. 1.2. 3.1  Translation 

For  targets  or  target  cluster  information,  tie  system  shall  perm  t 
translation/computation/tailoring  of  the  data  in  this  processing  s taco- 
such  that: 

1.  internally  coded  data  elements  can  be  translated  to  coded 
forms  used  by  the  recipient  systems  or  tne  targeting  analyst 

2.  coordinate  data  can  be  translated  to  forms  used  by  recipient 
systems 
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3.  in  the  case  of  target  cluster  processing,  statistical 
processes  or  best  parameter  se lection/subs t i tut  1  on  can 
be  rendered  to  ensure  best  target,  location  and  location 
error  data  is  provided  in  the  mission  request. 

For  query/SRI ,  the  translation  step  snail  additionally  translate 
parameter  values  in  conjunction  with  the  formatting  step  below.  Similar 
translation  shall  occur  for  received  responses. 

3. 1 . 2 . 3. 2  Forma tt i ng/Qissemi nat l on/ L  i  nkaye 

The  system  shall  provide  the  necessary  software  support  steps  to 
determine  by  the  choice  of  an  analyst  initiated  command  what  format 
conversions  are  required  and  what  information  elements  need  be  furtner 
supplied  by  the  analyst. 

The  system  will  automatically  perform  the  required  translating/ 
computation/tailoring  of  the  data  arui  format  a  resultant  message  in 
(a)  TACFIRE  fire  mission  request  format  and  transmit  the  message  to 
TACFIRE,  (b)  a  TACFIRE  target  report  in  AT  I /CUR  format,  (c)  Fire 
Mission  and  Target  Reports  to  the  remaining  identified  weapon  and 
intelligence  interfaces  when  defined. 

The  analyst  shall  likewise  he  permitted  to  indicate  by  command 
that  he  wants  to  view  the  modifiable  prestored  query/SI'I  menu  and 
select  an  appropriate  modifiable  prestored  query. 

After  modification  the  analyst  shall  be  capable  of  indication 
local  or  external  node  query  is  desired  and,  if  appropriate 
for  that  query 


The  system  shall  aut:>-  «t  ka’  ly  format  it,  transmit  it  and 
monitor  for  esponse  an :iuf.  tne  response  to  the  initiating 
query  for  work  queue  and  display  purposes. 

The  time  to  select  the  first  pane  of  a  query  menu  by  simple  command 
shall  not  exceed  2  seconds,  and  a  local  query  requiring  a  file  search 
(but  no  summary  processing  on  output)  shall  not  exceed  10  seconds.  Lach 
requirement  shall  be  met  or  bettered  at  least  80  percent  of  the  time. 

3. 1.2. 4  Targeting  Control  Suo function 

Figure  3.1.2-13  indicates  the  inputs,  processes  and  outputs  for 
the  targeting  control  subfunction.  This  subfunction  shall  permit  the 
targeting  analyst  to  control  on-line: 

1.  the  area  defintions  contained  in  the  control  record  (geometry) 
portion  of  the  targeting  data  base 

2.  by  mode  selection,  tne  set  of  algorithm  control  tables 
for  current  filtering,  correlation,  association,  and 
assignment  within  the  system. 

It  shall  be  possible  to  modify  ail  tables  (including  the  filtering, 
correlation,  association,  and  assignment  tables)  as  well  as  all  data 
base  records  (including  the  area  definitions  in  the  data  base)  by  means 
of  background  task  initiation  of  the  appropriate  modules  specified  in 
paragraph  3.2.2. 
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The  targeting  control  function  shall  also  permit  the  targeting 
analyst  to  transmit  command  guidance  messages  to  externally  interfacing 
nodes.  The  command  guidance  messages  shall  include: 

1.  Reporting  instructions  to  sensor  nodes  setting  conditions  for 
reporting  target  messages  to  the  D1VRAS  system  as  well  as 
instructions  to  the  sensor  nodes  setting  conditions  under 
which  the  sensor  will  additionally  directly  report  a  message 
to  a  weapon  system. 

2.  Battlefield  geometry,  zones  of  maneuver  and  rules  of  engage¬ 
ment  guidance  to  both  sensor  and  weapon  nodes. 

The  analyst  shall  be  supported  in  a  flexible  manner  in  accomplish¬ 
ing  these  control  functions  with  extensive  use  of  menu  and  light  pen 
selection  as  described  in  the  preceding  paragraph  3. 1.2. 3.  Again, 
translation/formatting  and  dissemination  support  stial  1  be  rendered  by 
the  system. 


3.1.3  Maneuver  Application 


GENERAL 

The  objective  of  the  maneuver  application  function  within  DIVRAS 
is  to  support  the  Oivision  Commander  and  his  inmediate  staff  through  an 
interactive  graphic  display  of  the  battle  situation  made  more  current 
through  use  of  real  time  sensor  inputs  to  update  enemy  force  locations. 
Figure  3. 1.3-1  presents  an  overview  of  the  maneuver  application  in  terms 
of  innuts,  subfunctions  (processes),  and  outputs.  Details  regarding 
incut  data  rates  are  included  in  Section  3.2.3;  representative  message 
formats  are  included  in  Appendix  1.  A  more  detailed  description  of  the 
operational  concept  is  included  in  the  DIVRAS  Final  Report  dated  3  August 
1977.  Subsequent  sections  will  specify  subfunction  requirements  in  more 
detail. 

3. 1.3.1  Shooter/Mover/Emitter  Processing  Subfunction 

Figure  3. 1.3-2  provides  an  overview  of  the  inputs,  processes  and 
outputs  of  the  Shooter/Mover/Emitter  (S/M/E)  Processing  Subfunction. 

S/M/E  message  traffic  shall  be  forwarded  from  indicated  sources  as 
defined  in  Section  3.1.1  in  accordance  with  message  formats  included  in 
Appendix  1 . 

Without  operator  intervention  the  system  shall  process  the  data 
into  file. 

Validity  checking  and  editing  shall  bo  accomplished  as  the  data  is 
processed  into  file. 


3 -So 


The  operator  at  a  terminal  shall  be  able  to  call  a  Shooter/Mover/ 
Emitter  overlay  one  at  a  time  by  actuating  a  single  function  key  for 
each  type  (i.e.,  one  key  for  shooters,  one  for  movers,  and  one  for 
emi tters ) . 

The  operator  shall  be  able  to  superimpose  two  or  more  S/M/E  over¬ 
lays  on  a  single  terminal  simultaneously. 

The  operator  shall  be  able  to  display  a  Shooter,  Mover  or  Emitter 
overlay(s)  on  any  level  of  map  background  indicated  in  Subsection  3. 1.3. 4. 
Figure  3. 1.3-3  shows  representative  Adjunct  Displays  superimposed  on  a 
map  background. 

The  S/M/E  sensor  location  data,  blocked  on  periodic  reporting 
intervals  (see  paragraph  3.1.1)  shall  be  further  processed  into  (1)  a 
file  under  data  base  manager  control  for  further  maintenance  and  query 
purposes,  and  (2)  a  self-purging  buffer  for  graphics  presentation  upon 
maneuver  analyst  call  up. 

The  graphics  presentation  buffer  shall  contain  varying  time  lengths 
(multiples  of  the  time  interval  discussed  in  paragraph  3.1.1)  cc  S/M/E 
data. 


These  varying  time  lengths  snail  be  pre-set  for  each  category 
of  input  data,  but  changeable  by  operator  action  similar  to 
changing  parameters  in  a  standing  query. 

It  shall  be  possible  to  delete  an  S/M/E  overlay  without  affecting 
other  overlays  that  it  may  be  super  imposed  upon. 

The  system  shall  be  capable  of  identifying  and  storing  at  least  10 
separate  S/M/ E  overlays  for  future  recall. 


The  operator  must  be  able  to  superimpose  one  adjunct  display  or 
more  in  red  over  a  situation  display  already  on  the  screen  in  3  colors 
(incl uding  red) . 

When  the  adjunct  overlay  is  deleted,  the  situation  display 
shall  remain. 

The  system  shall  provide  capability  for  purging  of  the  S/M/E  data 
based  on  age  of  the  data  (see  Section  3.2.2. 2). 

It  shall  be  possible  to  set  purge  criteria  independently  for 
each  category  of  input  data,  and  to  change  each  individually 
once  set. 

3. 1.3. 2  Maneuver  Situation  Monitoring  and  Update  Subfunction 

Figure  3. 1.3-4  provides  an  overview  of  the  input,  processes  and 
outputs  of  the  Maneuver  Situation  Monitoring  and  Update  Subfunction. 

The  objective  of  this  subfunction  is  to  provide  the  capability  to 
maintain  within  the  DIVRAS  data  base  the  results  of  intelligence  and 
operations  analyses  (ongoing  functions  performed  in  the  DTOC)  regarding 
locations  and  status  of  enemy  and  friendly  units  and  to  display  specific 
portions  of  this  data  on  operator  request.  This  data  base  forms  a  con¬ 
tinuously  evolving  baseline  for  use  in  updating  the  maneuver  situation 
through  comparison  with  real  time  sensor  inputs,  i.e.,  Mover/Shooter/ 
tmi tter  overl ays . 

3. 1.3. 2.1  Unit  Situation  Display 


access 


The  operator  shall  have  the  ability 
create  the  situation  display  on  request. 


Df,*-  data  needed  to 


•  Display  of  unit  locations 

Receive  specified  message  inputs  and  process  over  map  backgrounds  using 


FIGURE!  3. 1.3-4.  "ANE  LIVER  SITUATION  MONITORING  AND  UPDATE  SUBFUNCTION 


The  operator  shall  have  the  capability  to  call  up  a  display  of 
enemy  and  friendly  unit  locations  displayed  in  standard  F'i  21-30  unit 
symbology  over  a  map  background.  For  identification  purposes  this 
display  is  called  "Unit  Situation  Display".  Operator-controllable 
parameters  shall  include  (1)  friendly  or  enemy,  (2)  geographic  area, 

(3)  echelon  (lowest  level  to  be  shown). 

The  subfunction  shall  be  capable  of  utilizing  TOS  data 
containing  finished  intelligence  about  enemy  unit  locations 
and  status  and  presenting  it  at  the  Unit  Situation  Display. 

it  will  provide  access  to  the  FRENSIT  application  in  TOS 
and  present  current  location  and  status  information  about 
friendly  units. 

These  parameters  shall  be  enterable  at  the  maneuver  analyst’s 
termi nal . 

To  the  extent  that  unit  identification  data  is  available  in  the 
data  base,  the  system  shall  automatically  assemble  unit  symbols 
including  unit  numbers  for  display  at  the  appropriate  location  on  the 
screen . 

Where  no  unit  ID  is  available,  a  simple  open  box  will  be 
util ized. 

Symbols  shall  be  displayed  so  that  the  lower  left  hand  corner  of 
the  unit  symbol  corresponds  to  the  coordinates  in  the  data  base  indi¬ 
cating  unit  location.  Figure  3. 1.3-5  shows  a  representative  Unit 
Situation  Display. 

Overlapping  and  superimposition  of  symbols  is  allowable. 
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3. 1.3. 2. 2  Simplified  Commander's  Display  (Threat  Display) 

Through  use  of  console  controls  and/or  function  keys,  the  operator 
shall  have  the  capability  to  aggregate  elements  into  larger  forces  and 
represent  that  aggregation  through  use  of  appropriate  symbology.  For 
identification  purposes  this  display  is  called  "Threat  Display";  a 
representative  Threat  Display  is  shown  in  Figure  3. 1 . 3-6  superimposed 
on  a  primary  map  background. 

The  system  shall  retain  data  accessible  by  the  terminal  operator 
indicating  which  specific  units  are  aggregated  into  each  aggregated 
symbol . 

Capability  to  selectively  delete  or  add  overlays  of  map  background 
to  the  Threat  Display  shall  oe  provided  at  the  terminal. 

The  operator  shall  be  able  to  draw  the  Threat  Display  unit  boundary 
lines  and  forward  edge  of  the  battle  area  (FEBA)  interactively  from  his 
terminal . 

The  operator  shall  have  the  capability  at  the  terminal  to  selec¬ 
tively  call  up  Shooter/Mover/Emitter  overlays  for  superimposition  on 
the  Threat  Display.  (Figure  3. 1.3-7  is  representative  of  emitters 
overlaid  on  a  Threat  Display). 

The  operator  shall  have  capability  to  label  and  store  up  to  12 
Threat  scenes  in  permanent  or  temporary  storage,  either  individually 
or  overlaid,  for  future  recall. 
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3.1 .3.3  Symbology 


3. 1.3. 3.1  Standard  Symbols 

The  system  shall  generate  and  display  the  64  alphanumeric  symbols 
in  accordance  with  the  ASCII  set. 

3. 1.3. 3. 2  Military  Unit  Symbols 

The  system  shall  generate  and  be  capable  of  displaying  a  set  of 
standard  military  unit  symbols. 

The  symbols  shall  be  designed  to  resemble  those  illustrated  in 
FM  21-30  (Figure  3. 1.3-8). 

The  symbol  shapes  may  be  modified  to  allow  more  efficient 
display  of  curved  lines  by  substituting  a  series  of  short 
segments . 

The  system  shall  provide  the  capability  for  superimposing  branch 
symbols  to  create  a  composite  symbol. 

The  point  location  of  a  symbol  shall  be  indicated  by  the  lower 
left  hand  corner  of  the  symbol  for  rectangular  symbols  and  at  the  center 
for  round  symbols. 

Military  symbols  shall  be  presented  in  at  least  two  recognisable 
sizes.  These  shall  measure  approximately  1/2"  x  11/16"  for  the  larger 
flag  symbol  and  3/8"  x  1/2"  for  the  smaller  flag  symbol. 

The  difference  in  size  ratio  shall  be  not  less  than  1:1.33 
and  shall  be  great  enough  to  allow  the  operator  to  recognize 
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ECHELON 

ARMY 

Ariny 

xxxx 

CORP 

Corps 

XXX 

DIV 

Division 

XX 

BRIG 

Brigade 

X 

RGT 

Regiment 

III 

BN 

Battalion 

II 

CM 

Company 

1 

UNIT  DESIGNATIONS 

UNIT 

Unit 

f  Rectangle 

AA 

Army  Air 

Propeller 

AB 

Ai rborne 

Gull's  Wi ngs 

AD 

Air  Defense 

Radar  Dome 

ATY 

Arti 1 lery 

•  Cannon  Ball 

CAV 

Cavalry 

bandoleer 

ENG 

Engineer 

III  F  -  in  Side 

INF 

Infantry 

Crossed  Straps 

MECH 

Mechanized 

Tank  Track 

TRAN 

Transportation 

Whee  1 

MSSL 

Missile 

Warhead 

F I  JURE  3. 1.3-8.  TYPICAL  STANDARD  MILITARY  UNIT  SYMB'ILB 
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the  size  of  a  single  symbol  without  having  examples  of  both 
sizes  displayed  on  the  screen  for  comparison. 

Symbol  size  displayed  shall  remain  unchanged  when  the  screen 
image  is  expanded  or  contracted. 

Standard  unit  symbols  generated  automatically  or  in  response  to 
manual  input  instructions  for  display  on  the  Maneuver  graphics  screen 
shall  be  displayed  in  red  if  enemy  and  in  blue  if  friendly. 

3. 1.3. 3. 3  Military  Graphic  Symbols 

The  system  shall  generate  and  be  capable  of  displaying  the  military 
graphic  symbols  of  the  type  shown  in  Figure  3. 1.3-9. 

The  system  shall  provide  the  capability  to  create  and  display  at 
least  10  additional  special  symbols. 

Once  created  and  the  title  has  beer  added  to  the  symbol 
library,  these  special  symbols  shall  be  as  accessible  for 
use  as  military  graphic  symbols. 

The  military  graphics  symbols  shall  appear  in  a  color  which 
associates  them  with  friendly  action,  enemy  action,  or  geographic 
background.  (Color  indications  in  Figure  3. 1.3-3  are  representative.) 

3. 1.3. 3. 4  Threat  Symbols 

Ability  to  create  and  display  special  symbols  of  the  type  shown 
in  Figure  3.1.3-10  shall  be  provided. 
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IDENTIFICATION 

Obstacle  or 
Built-up  Area 

Obstacle  Minefield 

Zone  Receiving 
Artillery  Fire 

Zone  Receiving 
Air  Attack 

Swamp  or  Marsh 

Bridge 

Ra i 1  road  Track 


SYMBOL 


^  ✓  /  /  / 


COLOR 

Green 

Green 

EN  Fire  -  Red 
FR  Fire  7  Blue 

IN  Air  Red 

(R  Air  Blue 

Green 

Green 

Green 


Vegetation 


0  {>  0 
0  0 


Green 


Fir.URl  3.1.  3-fJ .  TYPICAL  MILITARY  GRAPHIC  SYMBOL  S 
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TITLE 


SYMBOL 


NOTES 


Threat  Force 
Advancing 


Threat  Force 
Blocked 


Stationary 

Force 


Blocking  Force 
in  Position 


Blocking  Force 
at  Planned  Position 


<o 


•  360°  orientation  capability  for 
indicating  direction 

•  Numeral(s)  for  indicating  count 
of  maneuver  battalion 


•  Three  parallel  lines  and  arrow 
are  in  opposite  colors 


•  This  symbol  is  used  for  a  force 
in  reserve  but  capable  of  becoming 
a  threat  force  within  a  specific 
time  interval 


•  360°  orientation  capability  for 
indicating  direction 

•  Numeral (s)  for  indicating  count 
of  maneuver  battalions 


ri 

1  2  I 
L  J 


FIGURE  3.1.3-10.  TYPICAL  SYMBOLS  FOR  THREAT  SCENE  DISPLAY 


Threat  scene  symbols  shall  be  designed  so  that  they  may  be 
displayed  in  a  range  of  sizes  and  aspect  ratios. 

The  system  shall  provide  the  operator  the  ability  to  vary 
a  Threat  symbol 's  length  over  a  range  from  one  to  4  and 
independently  vary  the  same  symbol's  width  in  a  range  from 
one  to  4. 

The  smallest  size  symbol  shall  equate  to  approximately  2.0  Km  in 
length  and  1.5  KM  in  width  when  presented  against  a  l:lu0,000  map 
ba  :kground. 

The  symbol  size  displayed  will  remain  unchanged  when  the  screen 
image  is  expanded  or  contracted. 

3. 1.3. 3. 5  Adjunct  (S/M/E)  Symbols 

The  system  shall  generate  and  be  capable  of  displaying  special 
symbols  of  the  type  shown  in  Figure  3.1.3-11. 

The  point  location  of  a  symbol  shall  be  defined  by  the  center  of 
the  symbol . 

The  adjunct  symbols  shall  be  presented  at  a  fixed  size  for  all 
display  scales. 

All  adjunct  symbols  shall  be  presented  in  red. 


SIZE 

TITLE  (APPROXIMATE)  SYMBOL 


NOTES 


EMITTERS 

Radar  1/4"  X  3/8" 


Communications  1/8" 

Emi tters 


*  Each  symbol  displayed 

represents  an  emitter 
detection  made  during 
a  predetermined  time 
1 1  .  interval 


SHOOTERS 

Artillery  3/16"  ^ 

Each  symbol  displayed 
represents  detection 
of  a  gun  firing  during 
a  predetermined  time 
interval 

Missile  or  Rocket  3/8"  X  3/8“ 


MOVERS 


Tracked  or  Wheeled  w 4..  x  3/^. 
Vehicle 


Each  symbol  displayed 
represents  detection 
of  from  1  to  10  movers 
during  a  predetermined 
time  interval 


FIGURE  3.1.3-11.  SYMBOL  SET  FOR  ADJUNCT  DISPLAY 
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3. 1.3. 4  Map  Backgrounds 


The  system  shall  be  designed  to  provide  the  user  with  several 
levels  of  map  background  detail,  each  callable  for  separate  display 
or  to  be  superimposed  with  one  or  more  of  the  other  map  backgrounds. 

It  shall  be  possible  to  superimpose  one  or  any  combination  of 
these  map  backgrounds  on  the  current  threat  scene,  the  current  adjunct 
scenes,  or  on  any  previously  stored  threat  or  adjunct  scene  which  has 
been  recalled  to  the  display  screen. 

In  addition  to  the  call  up  and  display  of  pre-stored  digitized 
map  information,  the  system  shall  provide  the  operator  with  a  limited 
capability  to  create,  modify,  label  and  store  the  digitized  map  data 
from  the  terminal. 

3.1 .3.4.1  Levels  of  Detail 

The  following  levels  of  map  background  detail  shall  be  separately 
callable: 

1.  A  digitized,  outline  level  map  providing  only  gross  map 
features.  These  shall  be  limited  to  principal  rivers  and 
bodies  of  water,  primary  roads  and  bridges,  and  major 
cities . 

This  map  shall  have  incorporated  on  its  horizontal  and 
vertical  borders  near  the  screen  edges,  labeled  tick  marks 
in  MGR  values.  Grid  ticks  will  be  incorporated  at  10  Km 
intervals  over  the  entire  map  face. 
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2.  A  digitized,  mid-level  map  including  additional  rivers  and 
bodies  of  water,  secondary  roads  and  bridges,  railroads, 
and  other  cities  not  included  on  the  outline  map. 

3.  A  digitized  terrain  map  including  items  such  as  heavy 
vegetation  areas,  swamps  and  marshy  areas  and  elevation 
high  points. 

4.  A  digitized  grid  tick  map  displaying  grid  ticks  and  MGR 
labels  in  the  central  portion  of  the  enemy's  frontal  area 
so  located  as  to  remain  visible  on  the  screen  for  most 
normally  used  expansion  factors  when  the  border  located 
grid  ticks  are  removed  from  view  by  the  expansion. 

3. 1.3. 4. 2  Area  Coverage  and  Scale 

To  depict  the  division  level  area  of  interest  in  full,  an  area 
coverage  of  at  least  70  x  90  kilometers  shall  be  maintained  in  active 
storage  (disk  or  other  high  speed,  random  access  media).  The  DIVRAS 
system  shall  have  the  capability  to  store  additional  map  areas  as 
fol lows : 

Small  Scale  Maps  (1:250,000)  =  300  km  along  FEBA  x 
300  km  deep 

Large  Scale  Maps  (1:50,000)  =  160  km  along  FEBA  x 
200  km  deep 

The  system  shall  have  the  capability  using  appropriate  interactive 
controls  to  expand  from  the  70  x  90  Km  map  scene  (called  the  XI  scale) 
up  to  a  scale  of  X8,  automatically  rescaling  and  displaying  all  map 
elements  contained  within  the  bounds  of  the  newly  selected  map  area. 


The  system  shall  have  capability  using  appropriate  interactive 
controls  to  contract  from  ariv  <:  ■  the  expanded  scale  map  areas  back  to 
any  smaller  scale  (larger  map  e.ea),  automatically  restoring,  rescaliny 
and  displaying  all  map  elements  formerly  contained  within  the  map  area 
of  concern. 

The  system  shall  permit  via  interactive  controls  the  scaling  and 
display  of  digitized  map  frames  at  exactly  the  scales  of  1:100,000  and 
1:50,000  whether  or  not  these  equate  to  an  integer  expansion  from  the 
XI  map  stored  by  the  system. 

3. 1.3. 4. 3  Map  Background  Color 

Map  background  details  will  be  displayed  in  a  single  color  selected 
to  be  clearly  distinguishable  from  those  used  for  displaying  friendly 
and  enemy  unit  and  threat  symbols  and  for  displaying  military  boundaries 
and  related  information. 

3. 1.3. 5  Operator  Graphic  Manipulation 

From  the  maneuver  analyst  terminal  the  operator  shall  be  capable 
of  interacting  with  the  Maneuver  Application  Software  to  perform  graphic 
manipulations  with  both  scenes  and  symbols.  Major  manipulation  capabili¬ 
ties  are  listed  in  Figure  3.1.3-12.  Specific  requirements  are  detailed 
below . 

3. 1.3. 5.1  Scene  Manipulation 

The  operator  shall  be  able  to  call,  superimpose  or  delete  in  any 
combination  the  following  set  of  graphic  scenes  as  described  in  the 
subsection  above: 
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:vance  to  next  scene,  or  advance/return  to 
specified  scene  in  a  sequence 


9 


njjjj'.Lt  Scenes 

Shooter  Overlay 
Mover  Overlay 
Emitter  Overlay 

uMt  Situation  Display 

Svclified  Commander's  (Threat)  Display 

Map  Background 

Primary  (Level  1) 

Secondary  (Level  2) 

Terrain  (Level  3) 

Expanded  MGR  Grid  (Level  4) 

T,v.  ape'rator  shall  be  able  to  store  and  label  for  future  recall 
tne  foi lowing  set  of  graphic  scenes: 

Adjunct  Scenes 

Shooter  Overlay 
Mover  Overlay 
Emitter  Overlay 

Simplified  Commanders  (Threat)  Display 

The  operator  shall  be  able  to  recall  in  time  sequence  the  previously 
stored  scenes  of  the  Simplified  Commander's  Display. 

Tne  operator  shall  be  able  to  expand  or  contract  any  scene  or 
mi;  eririuos i  Lion  of  scenes  that  are  being  currently  displayed  in  accor- 
tne  expansion  requirements  of  paragraph  3. 1.3. 4. 2. 

.-■oans'on  or  contraction  shall  occur  around  a  center 
'  .'ur.jted  on  the  display  by  means  of  an  interactive 
.  ■  ■)  .  i  rjr$or,  or  light  pen. 


Symbol  Manipulation 


The  operator  shall  be  able  to  position  and  display  interactively 
any  of  the  symbols  from  the  following  symbol  sets  as  described  in 

paragraph  3. 1.3. 3: 

Standard  Military  Unit  Symbols 
Military  Graphic  Symbols 
Threat  Symbols 

The  operator  shall  be  able  to  move  or  delete  interactively  from 
display  any  of  the  symbols  from  the  following  symbol  sets: 

Standard  Military  Unit  Symbols 
Military  Graphics  Symbols 
Threat  Symbols 

The  operator  shall  be  able  to  rotate  interactively  any  of  the 
Threat  symbols  in  order  to  indicate  the  orientation  or  direction  of 
the  represented  force. 

The  operator  shall  be  able  to  append  a  staff  to  any  of  the 
Standard  Military  Unit  symbols  and  to  offset  and  bend  the  staff. 

3. 1.3. 5. 3  General  Graphic  Manipulation  Capabilities 

The  operator  shall  be  able  to  interactively  draw  through  straight 
line  segments  the  following: 

FEBA  (using  dashed  lines) 

Unit  Boundaries 

Outlines  of  areas  of  tactical  interest. 


■  operator  shall  be  able  to  annotate  using  alphanumeric  charac- 
•„  any  point  on  the  screen  which  is  designated  by  the  cursor  (or 

t  pen). 

The  operator  shall  be  able  to  identify  any  symbol  on  the  display 
^actively  and  retrieve  through  data  base  query  any  information 
.  about  that  symbol. 

The  operator  shall  be  able  to  obtain  interactively  cursor  (or 
l  pen)  readout  in  MGR  coordinates  of  any  point  on  the  graphic 

.  a  y . 

Tne  operator  shall  be  able  to  obtain  interactively  straight  line 
.arces  in  meters  between  two  designated  points  on  the  graphic  displ 

Tne  operator  shall  be  able  to  control  the  time  interval  for  data 
layed  on  the  Shooter/Mover/Emitter  overlays  through  selection  of 
of  four  interval  settings. 

The  time  intervals  applied  for  each  Shooter,  Mover,  and 
Emitter  overlay  for  each  interval  setting  shall  be  enterable 
through  table  entry  at  the  operators  terminal. 


3.2  SYSTEM  SUPPORT  SOFTWARE 


3.2.1  Communications  Processing  Subsystem 

The  communications  processing  subsystem  shall  provide: 

1.  Communications  line  control  and  monitoring 

2.  Communication  task  supervision 

3.  Data  separation  and  buffering 

4.  System  logging  and  recovery 

5.  Interface  with  the  graphics/data  base  management  processing 
subsystems 

Figure  3.2. 1-1  portrays  the  relationship  of  the  processes  within  the 
communications  processing  subsystem. 

Line  Control/Monitoring 

This  subsystem  function  shall  terminate  the  external  communi cati o: 
lines  and  provide  control  for: 

1)  modem/cryptography  interfaces  (synchoni zati on/cl ocki ng) 

2)  line  data  receipt  and  transmission  (protocol  handling, 
serial/paral lei  data  conversions) 

3)  error  encoding/decoding  and  error  handling  (recovery/ 
retransmission) 

4)  line  state  diagnostics  (GO-NO-GO  line  monitoring,  wraparound 
isolation  checking,  test  message  transmission/receipt/ 
checking) . 
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Hardware/software  tradeoffs  are  required  when  actual  line  protocol 
and  electrical  interfaces  are  determined  to  assess  the  degree  to  which 
the  ^bove  functions  are  to  be  implemented  in  the  communications  pro¬ 
cessing  software  versus  per  line  or  multiplexed  line  hardware  or 
firmware  (microcode  function  circuits). 

Task  Supervisor 

The  task  supervisor  shall  control  the  taskable  subfunctions  within 
the  comrnuni cat  ions  processing  software  to  accomplish  the  communications 
processing  function.  It  shall  respond  to  each  hardware  control  signal 
coming  from  any  of  the  external  communication  lines  and  schedule  line 
control  processing  to  provide  appropriate  response  action.  (As  stated 
above,  this  can  be  on  a  bit  by  bit  basis  for  some  or  all  lines  depend¬ 
ing  on  hardware/software  tradeoffs.)  It  shall  also  respond  to  input/ 
output  commands  from  the  graphics/data  base  management  processing 
functions  and  either  directly  accomplish  or  schedule  appropriate 
response  action.  It  shall  also  queue  and  schedule  tasks  between 
communication  processing  subfunctions  as  a  result  of  each  subfunction 
task  completion. 

Data  Separation  and  Buffering 

This  subsystem  function  shall  process  all  incoming  information 
from  the  external  communication  lines  and  build  two  distinct  data 
queues  for  the  data  base  management  processing  (in  order  to  support 
the  targeting  and  maneuver  functions).  This  subsystem  shall  also 
provide  for  buffering  between  the  external  communication  line  rates 
and  the  asynchronous  graphics/data  base  management  processing  rates. 
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Figure  3.2. 1-2  indicates  the  data  separation  function.  The 
incoming  message  traffic  contains  target  messages  or  unit  data  messages 
as  well  as  messages  containing  a  group  of  detections  from  specific 
sensor  nodes.  The  data  separation  function  shall  take  all  of  this 
traffic  and  create:  1)  a  first-in  first-out  message  queue  which  will 
contain  enemy  or  friendly  unit  messages  and  enemy  activity  messages 
from  the  ENSIT/FRENSIT  applications  as  well  as  individual  targeting 
messages  from  the  sensors,  but  no  data  from  the  group  detection 
messages;  and  2)  a  time-grouped  queue  of  location  data  (organized  by 
shooter,  mover,  emitter)  assembled  from  the  group  detection  data  as 
well  as  the  SOTAS  target  message  data. 

Both  these  queues  shall  be  controlled  by  the  communications 
processing  function  to  ensure  no  loss  of  data  and  shall  be  passed  to 
the  graphics/data  base  management  function  on  demand  of  those  functions. 
The  demand  rate  for  the  first  queue  shall  be  asynchronous  with  the 
demand  interval  not  exceeding  180  seconds.  The  demand  rate  for  the 
second  queue  will  be  approximately  periodic  at  the  rate  of  the  time 
grouping  factor  stated  above.  This  time  grouping  factor  shall  be 
changeable  (between  5  and  15  minutes)  and  will  also  determine  the  group 
detection  message  reporting  periodicity  for  those  externally  affected 
nodes . 

Oata  Logging/Recovery 

The  data  logging/recovery  function  shall  record  all  messages  and 
detection  data  on  a  system  log.  In  certain  non-catastrophic  failure 
modes  of  short  duration,  it  shall  be  possible  to  play  back  from  the 
system  log  without  loss  of  any  data. 


Interface  to  Graphics/Uata  Base  Manat  ,ient  Processi ng 

The  communication  processing  subfunction  shall  provide  an  interface 
to  the  graphics/data  base  management  subsystem.  If  the  communication 
processing  subsystem  is  implemented  in  a  separate  computer  the  interface 
shall  be  accomplished  at  a  high  speed  computer  to  computer  transfer  rate. 
If  they  are  implemented  in  the  same  computer  they  shall  intercommunicate 
by  placing  data  in  commonly  accessible  storage.  Separate  facilities 
are  desired  to  permit  more  latitude  in  the  necessary  hardware/sof tware 
tradeoffs  to  be  accomplished  in  the  communi cati ons  processing  subsystem 
area . 
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3.2.2  Data  Base  Management  Subsystem 

The  data  base  management  programs  shall  support  both  the  targeting 
and  maneuver  applications  in  a  flexible  manner  to  enable  the  system  and 
operating  analysts  to: 

data  base,  retrieve  and  extract  all  required  data 

<  -  automatically  process  inputs  and  outputs  in  a  flexible 

manner  to  permit  easy  direction,  tailoring,  and  highlighting 
of  important  information 

readily  pursue  important  information  leads  on  an  ad  hoc 
basis 

easily  communicate  results  to  other  analysts  and  interfacing 
Systems . 

The  basic  data  base  management  programs  shall  contain  the  capabil¬ 
ities  for: 


structure  and  structure  revision  of  a  broad  set  of  files  in 
background  task  mode.  This  will  ensure  that  as  the  application 
functions  evolve,  the  data  base  can  flexibly  change  to  meet 
the  new  requirements  in  a  quick,  time  responsive  manner. 

complete  background  and  on-line  file  maintenance  to  include 
initialization,  change  and  purge  of  data  contained  within  the 
various  structured  files. 

background  and  foreground  (on-line)  operational  modes  to 
update,  logically  manipulate,  retrieve  and  output  data  to 
using  analysts  or  external  nodes. 
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complete  utility  processing  in  background  mode  to  permit 
definition,  compilation  and  linkage  of  user  interface 
routines  (tailoring)  as  well  as  library  storage  and 
maintenance  of  logic  statements,  reports  and  control 
dictionary/tables. 

Figure  3. 2. 2-1  presents  an  overview  of  the  inputs,  Qrocesses,  and 
outputs  which  shall  be  incorporated  in  the  data  base  management  function. 
Basic  inputs  are  in  the  form  of: 

Local  terminal  network  inputs 

Graphic  processing  inputs  (cursor/controls) 

Communication  subsystem  inputs 
Background  task  initiations 

Basic  outputs  are: 

Local  terminal  network  outputs 

Outputs  to  graphics  processing  (qualified  record  data  for 
graphical  display) 

Outputs  to  the  connuni cations  subsystem 

Outputs  to  the  operating  system  job  queue  (task  initiation) 

In  addition  to  these  specific  inputs  and  outputs,  the  data  base, 
as  indicated  on  Figure  3. 2. 2-1 ,  is  often  an  input/output  for  many  of 
the  processes. 
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FIGURE  3.2.2*].  DATA  BASE  MANAGEMENT  SUBSYSTEM  OVERVIEW 


3. 2. 2.1  File  Structuring/Revision 


The  file  structuring/revision  subfunction  shall  permit,  in  back¬ 
ground  mode,  the  creation  and  reorganization  of  file  structures  which 
are  supportive  of  the  targeting,  maneuver,  functions.  This  subfunction 
shall  permit  non-programmers  to  specify  data  structures  required  to 
support  the  applications  and  evolution  of  these  applications.  This  shall 
be  accomplished  by  a  simple  language  convenient  to  the  user.  The  file 
structuring  subfunction,  together  with  the  operating  system,  shall  permit 
a  high  degree  of  independence  from  the  physical  data  storage. 

File  Concept 

The  system  shall  permit  management  of  a  broad  spectrum  of  data  in 
an  organizational  manner  equivalent  to  the  hierarchical  organization 
shown  on  Figure  3. 2. 2-2.  The  description  below  is  representative  of 
the  flexibility  of  the  file  structure  necessary  to  support  the 
targe ti ng/maneuver  appl i cati on . 

The  terms  used  in  this  subparagraph  are  defined  as  follows: 

A  collection  of  data,  supporting  the  general  mission 
or  applications  of  the  system.  It  is  typically  com¬ 
posed  of  many  different  logical  data  sets  ( corrmoniy 
cal  led  fi 1 es ) . 

A  logical  set  of  data  elements,  grouped  into  associ¬ 
ated  arrays  called  records. 

That  collection  of  data  elements  identifiable  by  a 
unique  data  value  or  key. 


Data  Base 


Data  File 


Data  File 
Records 
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UNCLASSIFIED 


Field 


A  single  data  element. 


The  capability  to  index,  or  access,  the  contents  of 
a  data  file  by  a  means  other  than  the  record  identi¬ 
fier.  The  index  data  set  is  a  logical  data  set  of 
all  index  values  and  the  data  records  associated 
with  each. 

It  shall  be  possible  to  carry  both  repetitive  and  nonrepeti ti ve 
information  in  a  file  record  in  fixed  and  periodic  information  sets. 
Collections  of  field  strings  having  the  same  format  are  called  sets. 
Therefore,  the  string  of  fields  containing  nonrepeti ti ve  data  in  a  file 
record  shall  be  defined  as  the  fixed  set.  Periodic  fields,  grouped  and 
recurring  as  strings,  are  defined  as  periodic  sets. 

The  record  structure  within  a  file  shall  contain  a  fixed  set,  with 
one  level  of  subordination  (the  periodic  set  or  sets).  The  format  of  a 
fixed  set  shall  be  constant  throughout  one  file.  More  than  one  periodic 
set  may  be  defined  in  the  file  structure,  but  as  in  the  case  of  the 
fixed  set,  the  format  shall  be  constant  throughout  the  file  on  a  set-by¬ 
set  basis.  In  other  words,  the  format  of  the  first  periodic  set  in  each 
record  is  the  same,  and  the  format  of  the  second  periodic  set  in  each 
record  is  the  same  and  so  on.  The  formats  of  periodic  set  1  and  periodic 
set  n,  however,  need  not  be  the  same. 

The  user  shall  be  able  to: 

include  a  variable  field  within  the  definition  of  each  of  the 
fixed  or  periodic  sets.  (This  field  can  contain  variable 
length  character  strings  and  shall  be  included  in  physical 
storage  only  when  there  is  actual  data  in  the  field.) 


Secondary/ 

Keyword 

Indexing 
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structure  several  variable  sets.  (Each  variable  set  contains 
a  variable  length  character  string  and  shall  exist  only  when 
data  is  present.) 

retrieve  records  based  on  the  content  of  variable  data  fields 
by  either  executing  a  scan  of  the  field  for  the  qualifying 
value(s)  or  by  employing  the  keyword  indexing  capability. 

Secondary  and  keyword  indexing  capabilities  shall  be  available  to 
enable  a  user  to  have  more  flexible  control  over  his  data.  Secondary 
indexing  shall  permit  the  specification  of  fixed-length  fields  as  indexes 
and  retrieval  of  records  based  on  the  contents  of  those  fields.  Keyword 
indexing  shall  permit  the  specification  of  variable  fields,  variable 
sets,  and  fixed-length  fields  as  indexes;  selecting  values  from  the 
field  as  keywords;  and  retrieving  records  based  on  the  presence  of  the 
keywords  within  the  queried  fields. 

File  Structuring 

File  records  (the  collection  of  the  fixed,  periodic,  and  variable 
sets  which  are  uniquely  identified  by  a  record  identifier  or  key)  shall 
not  be  defined  as  to  size.  The  system  shall  perform  dynamically,  giving 
the  user  a  high  degree  of  flexibility.  The  system  shall  load  into  memory 
only  those  sets  referenced  by  the  job,  thereby  effectively  permitting  a 
significant  record  size. 

During  the  file  definition  process,  the  user  shall  be  able  to 
specify  in  advance  certain  automatic  functions  such  as  conversion  of 
retrieval  literals  to  coded  file  values,  output  data  conversions,  or 
editing.  If  file  indexing  is  desired,  the  user  shall  be  able  to  indi¬ 
cate  which  field  or  fields  will  provide  the  index  values.  The  file 
structuring  subfunction  shall  provide  mechanisms  for  this  purpose  and 
record  these  characteristics  in  the  basic  File  Format  Table  (FFT). 
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Record  control  or  key  fields  may  be  defined  as  a  single  field  or  a 
string  of  multiple  fields.  Periodic  subsets  may  also  have  data  fields 
assigned  for  sequencing  and  control  within  the  record.  If  the  user 
does  not  desire  to  provide  these  subset  control  elements,  the  system 
shall  create  sequence  numbers  for  the  control  function  and  maintain 
them  as  a  normal  part  of  the  background  file  maintenance  subfunction 
(paragraph  3. 2. 2. 2). 

The  file  structuring  subfunction  shall  provide  a  simple,  convenient 
way  for  the  user  to  specify  his  file  format  and  requirements.  Using  a 
simple  free-format  language  which  uses  default  options,  the  user  shall 
be  able  to  specify  the  logical  data  associations  he  desires. 

Additionally,  the  file  structuring  subfunction  shall  provide  for: 

Subroutines/tables  for  update/maintenance  (such  as  trans¬ 
lation)  associated  with  each  file 

Edit  masks  definable  for  each  file. 

In  the  UIVRAS  system  certain  files  shall  be  placed  under  data 
management  control  while  others  shall  contain  data  required  for  rapid 
graphics  display  call  up  and  need  not  be  formally  accessed  under  the 
data  management  subsystem.  Shooter/move r/emi tter  detection  data 
required  to  support  the  maneuver  application  shall  be  placed  under 
data  management  control  for  query  purposes  as  well  as  processed  into 
a  separate  file  for  rapid  display  call  up. 

Figure  3. 2. 2. -3  diagrams  the  essential  contents  of  the  files. 
Appendix  II  represents  a  formatted  file  table  for  the  Targeting/Maneuver 
data  file  which  is  one  of  the  two  under  data  management  control.  It 
shall  contain  enemy  unit,  enemy  activity  and  friendly  unit,  disposition 
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and  status  information  obtained  from  the  TOS  ENSIT/FRENSIT  applications 
as  well  as  targeting  and  control  information.  For  this  file,  one  record 
definition  is  assumed.  Although  equivalent  functional  alternatives  shall 
be  permitted,  the  discussion  below  is  based  on  the  assumption  of  one 
record  definition  and  is  included  to  indicate  the  structured  flexibility 
required  to  support  the  targeting  and  maneuver  application. 

Within  the  one  record  definition  it  shall  be  possible,  as  a  minimum, 
to  distinguish  between  enemy,  friendly,  and  control  record  types.  (The 
control  record  types  contain  definition  information  associated  with 
targeting  control  and  rules  of  engagement.)  Each  record  shall  have  the 
same  record  format  and  differ  only  in  the  physically  stored  subsets  of 
information. 

For  example,  an  enemy  record  describing  an  enemy  unit  would  contain 

the  fixed  set  and  as  many  polygon  subsets  as  desired  if  there  were  area 

definable  characteristics  associated  with  the  enemy  unit  (e.g.,  region 
of  operation,  zone  of  fire--if  fire  unit,  etc.).  Also,  it  would  contain 
the  unit  data  periodic  set  as  well  as  the  target  data  (or  enemy  activity 
data)  periodic  subset  if  any  target  or  enemy  activity  were  associated 
with  the  unit.  It  could  contain  as  many  "remarks"  periodic  subsets  as 
desired  annotating  this  enemy  unit. 

Another  example  would  be  an  enemy  record  describing  a  target.  In 

this  case  the  record  would  contain  the  fixed  set  and  as  many  polygon 

subsets  as  desired  to  describe  area  definable  characteristics  associated 
with  the  target.  Also,  it  would  contain  the  target  (or  activity)  data 
periodic  subset  and  as  many  remarks  subsets  as  desired. 
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File  Revision 


The  file  structuring/revision  subfunction  shall  also  provide  the 
capability  to  revise  the  format  in  which  data  is  stored  in  a  data  file. 
This  shall  be  accomplished  by  the  comparison  of  the  FFT  describing  the 
file  in  its  current  format  to  the  FFT  in  its  revised  format.  The  system 
shall  then  generate,  as  a  result  of  the  comparison,  file  maintenance 
logic  statements  which  will  be  used  by  the  file  maintenance  subfunction 
(paragraph  3. 2. 2. 2)  to  copy  selected  data  elements  into  the  new  format. 

It  shall  be  possible,  under  the  file  revision  subfunction,  to: 

add,  delete,  relocate  fields  as  well  as  change  their  storage 
mode,  size  and  name 

delete,  relocate  or  add  periodic  sets  (on  adding  a  periodic 
set  no  data  will  be  included  as  a  result  of  the  file  revision 
subfunction) 

split  any  set  in  the  old  file  into  several  sets  in  the  new 
fi  le 

modify  all  file  maintenance  logic  statements  generated  by 
the  file  revision  subfunction  under  user  control. 

3. 2. 2. 2  File  Generation  and  Maintenance 

The  file  maintenance  subfunction  shall  provide  the  user  with  a 
background  mode  capability  for  generating  and  maintaining  data  files. 

The  user  shall  be  able  to  add,  delete,  or  change  file  records,  periodic 
sets  or  subsets,  and  variable  sets.  Also,  the  user  may  modify  or  change 
file  fields  and  may  change  (increase  or  decrease)  the  volume  of  data 
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associated  with  any  file  record.  If  indexing  is  specified  for  the  file, 
the  index  data  set  shall  also  be  maintained.  This  index  data  set  main¬ 
tenance  shall  be  automatic  and  transparent  to  the  user. 

All  processing  shall  be  controlled  by  logic  statements  provided  by 
the  user.  These  statements  may  be  in  either  a  macro-like  programmer- 
oriented  language  or  a  high-level  procedural  English-like  language 
which  shall  be  easy  to  learn  and  simple  to  use.  The  languages  shall 
include  instructions  that  permit  automatic  table  translation  and  vali¬ 
dation  or  automatic  linkage  to  user  provided,  special  purpose, 
subroutines . 

The  system  shall  provide  an  on-line  counterpart  to  this  file  main¬ 
tenance  capability  (see  subparagraph  3. 2. 2. 4). 

Data  Initialization 


A  method  shall  be  established  to  initialize  the  enemy  unit  and 
friendly  unit  data  required  for  targeting  and  maneuver  from  the  TOS 
ENSIT/FRENSIT  applications.  After  initialization,  the  appropriate  new 
or  changed  unit/activity  information  shall  be  made  available  in  real 
time  to  the  Targeting/Maneuver  applications  from  the  TOS  ENSIT/FRENSIT 
applications.  The  targeting  control  parameters  (excluding  control  area 
definitions)  shall  be  initialized  at  their  default  value  with  permitted 
review  and  change  activity  initiated  by  manual  intervention.  Control 
area  definitions  will  be  initialized  manually.  The  remaining  targeting 
and  shooter/mover/emitter  location  data  is  not  initialized  but  is  input 
to  the  system  in  real  time. 
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Recovery 

A  method  shall  be  established  to  permit  the  DIVRAS  system  to  recover 
from  certain  short  period  outages  employing  system  log/recovery  process¬ 
ing  techniques.  Catastrophic  short  period  outages,  as  well  as  long 
duration  outages  will  not  be  recoverable  but  will  require  reinitialization 
of  the  system. 

Purge 

The  system  shall  permit  initiation  of  modifiable  prestored  purge 
commands  which  will  delete  data  base  information  which  is  no  longer 
needed.  The  modifiable  prestored  purge  commands  shall  be  capable  of 
logical  qualification  based  upon  combinatorial  logic  involving  virtu¬ 
ally  any  of  the  stored  data  base  fields.  It  shall  be  possible  for 
example  to  purge  based  upon  logical  combinations  of  time,  area,  target 
subject,  and  report  source.  The  control  table  governing  the  prestored 
purge  commands  shall  be  a  row/column  matrix  of  similar  structure  and 
flexibility  to  that  indicated  in  Figure  3. 1.2-3  (Filter  Logic  Rules)  of 
subparagraph  3. 1.2.1.  The  purge  process  shall  not  require  cessation  of 
the  on-line  (foreground)  functions.  Data  integrity  shall  be  preserved 
during  the  purge  process. 

3. 2. 2. 3  Retrieval  and  Sort  Processor 

The  data  management  system  shall  permit  background  use  of  a 
retrieval  and  sort  processor.  This  processor  shall  permit  broad  use 
of: 


automatic  library  maintenance  capabilities 
standing  queries 

compile  and  go  modes  of  operation 
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The  retrieval  and  sort  processor  shall  use  a  simple  English-like, 
free-format  condition/action  language  which  is  flexible  in  notation. 

By  specifying  the  retrieval  condition,  the  user  shall  be  able  to  select 
specific  records  to  be  retrieved  from  the  data  file.  Comparison  oper¬ 
ators  which  shall  be  provided  are  the  normal  equal  to,  less  than, 
greater  than  and  between.  All  may  be  preceded  by  the  negative  operator 
"not". 

Boolean  connectors  shall  be  permitted,  as  well  as  up  to  eight  levels  of 
nested  parentheses.  Two  geographic  retrieval  operators  shall  also  be 
provided:  irregular  area  and  circle  search.  The  former  shall  provide 
area-to-area ,  area-to-1 ine ,  1 ine-to-1 ine,  and  poi nt-to-area  capabilities 
and  shall  not  be  constrained  to  convex  area  definitions. 

The  retrieval  and  sort  processor  shall  be  capable  of  providing 
many  answer  sets,  each  of  different  control  or  sequence,  by  a  single 
pass  of  either  the  entire  data  file  or  only  those  records  selected  as 
possible  candidates  for  retrieval  by  index  processing.  Satisfaction 
of  the  condition  shall  assign  the  output  of  the  file  record  (or  a 
selected  portion  of  the  file  record)  to  a  temporary  file  for  later 
system  sequencing.  Each  condition  statement  may  have  several  associ¬ 
ated  sort  statements.  (A  sort  statement  is  the  string  of  fields  and/or 
literals  upon  which  the  user  desires  to  sequence  the  answer  records.) 
Conditions  may  be  prestored  with  their  associated  sort  statements  on 
the  query  library.  The  retrieval  and  sort  processor  shall  also  provide 
for  automatic  conversion  of  comparison  literals  from  external  form  to 
file  form  as  well  as  partial  field  notation  and/or  literal  masking. 

A  capability  similar  to  the  retrieval  and  sort  processor  shall  be 
available  in  on-line  mode  (see  paragraph  3. 2. Z. 4). 
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3. 2. 2. 4  Terminal  Processing  and  Display 

The  terminal  processing  and  display  subfunction  shall  make  data 
management  processing  system  attributes  for  maintaining,  updating, 
retrieving  and  reporting  data  available  on-line  (in  real  time)  to  the 
targeting  and  maneuver  applications.  This  shall  permit  automatic 
functioning  between  the  incoming  data  stream  and  the  data  base  (such  as 
target  of  interest  processing  -  paragraph  3. 1.2.1)  or  manual  interaction 
with  either  the  incoming/outgoing  data  stream  or  the  data  base  to  occur. 

As  indicated  in  Figure  3. 2. 2-1,  the  Terminal  Processing  and  Display 
subfunction  shall  contain: 

a  terminal  monitor 
a  query  processor 
an  on-line  update  processor 
edit  capabilities 
on-line  utility  support 

Terminal  Monitor 

The  terminal  monitor  shall  be  a  main  storage  resident  monitor  to 
service  local  terminal  device  or  other  processing  module  (i.e.,  graphics 
and  communication  processing  functions)  requests/interactions  arid  perform 
input/output  queuing.  Additionally,  one  or  more  terminal  processing 
supervisor(s)  may  be  required  to  control  tasking  between  the  terminal 
processing  subfunction  programs  (such  as  query  processor,  on-line 
update,  etc.)  and  the  terminal  or  other  program  users  depending  upon 
the  number  of  concurrent  tasks  dynamically  operating  in  the  system. 
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Output  generated  by  the  terminal  processing  subfunction  programs 
shall  be  made  available  to  the  terminal  user  for  paging  in  conversa¬ 
tional  mode  or  to  other  processing  modules  for  appropriate  processing 
such  as  communication  output  or  graphical  display. 

Query  Processor 

The  on-line  query  processor  shall  give  the  user  (either  terminal 
user  or  other  system  processing  module)  an  on-line  data  retrieval 
language  and  display  language  for  outputting  data.  Such  on-line 
processing  shall  include  the  capability  to  execute  modifiable  pre¬ 
stored  retrieval  commands. 

File  records  shall  be  qualified  for  output  by  simple  or  compound 
conditions  being  met.  Legal  subjects  of  the  conditional  expression 
shall  be  any  field  and/or  group  names.  The  query  processor  shall  be 
able  to  limit  the  number  of  data  records  that  must  be  examined  in 
detail  through  the  use  of  file  indexing  of  potential  candidate  records 
when  the  secondary  index  function  is  utilized. 

Relational  operators  shall  be  provided  for  equal  to,  greater  than, 
greater  than  or  equal,  less  than,  less  than  or  equal,  between,  and  noi- 
equal  conditions.  All  relational  operators  may  be  preceded  by  the 
negative  operator  'not'.  Geographic  search  operators  shall  be  provided 
for  determining  if  a  point  is  contained  within  an  area,  a  line  inter¬ 
sects  or  is  contained  within  an  area,  a  line  intersects  a  line,  or  an 
area  is  contained  within  or  overlays  an  area;  or  for  testing  if  a 
geographic  point  lies  within  a  circle  defined  by  a  literal  consisting 
of  a  point  and  radius. 

Any  geographic  area,  line,  or  point  shall  also  be  usable  as  the 
selection  criterion  for  producing  an  output  report. 
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The  query  processor  shall  also  provide  a  FUNCTION  operator  which 
allows  the  user  to  write  his  own  subroutine  to  assist  in  record  quali¬ 
fication  and  data  presentation.  The  FUNCTION  operator  shall  be  written 
as  a  conditional  clause  and  may  have  in  the  parameter  list  literals, 
indirect  address  literals  (item  names),  and  function  work  areas. 

Compound  conditional  expressions  shall  be  permitted  by  the  use  of 
the  logical  connectors  ANO  or  OR.  An  unlimited  number  and  level  of 
parentheses  shall  be  allowed,  and  where  nested  parentheses  are  used, 
the  expression  contained  in  the  most  deeply  nested  parentheses  is 
evaluated  first.  Successively  higher  levels  are  evaluated  until  the 
truth  factor  for  the  entire  statement  has  been  determined.  The  user 
shall  be  able  to  modify  the  logic  of  a  query  compound  expression  against 
an  item  of  a  repeating  group  with  the  ANY  modifier.  This  modifier  shall 
change  the  conditional  logic  so  that  successive  terms  against  the  same 
periodic  set  are  not  evaluated  within  one  subset  at  a  time,  thus  per¬ 
mitting  a  record  to  be  qualified  if  an  item  of  a  repeating  group  has 
different  values. 

The  query  processor  shall  provide  for  subroutine  conversion  to 
qualify  encoded  values.  Subroutine  conversion  may  be  specified  in  the 
retrieval  statement  or  performed  automatically  for  items  designated 
for  subroutine  conversion  at  file  definition  time.  This  automatic 
subroutine  conversion  may  be  suppressed  or  overridden  with  another 
subroutine  at  retrieval  time. 

The  query  processor  shall  provide  flexible  display  output  operators. 
As  an  example,  the  user  shall  be  permitted  the  capability  to  list  the 
contents  of  any  field  and/or  group  in  the  file  in  such  a  manner  as  to 
produce  a  columnar  report.  The  system  shall  generate  as  many  columns 
and  output  lines  as  needed  to  list  all  of  the  specified  fields;  however, 
if  all  the  fields  will  not  fit  on  a  single  line  of  output,  the  fields 
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will  be  stored  by  set  number  and  displayed  accordingly.  When  more  than 
one  output  line  is  generated  for  a  record,  all  lines,  except  the  first, 
shall  be  idented  to  be  easily  identified  as  a  continuation  of  a  record. 
Column  headings  shall  be  generated  automatically  from  the  output  labels 
associated  with  the  specified  fields/group  when  the  file  was  defined. 

If  no  output  label  was  assigned  to  the  field/group,  the  field/group 
name  shall  be  displayed. 

The  query  processor  shall  provide  for  computational/logical  tailor¬ 
ing  of  output  results  to  include  summation  and  counting  of  selected  data 
fields  prior  to  output. 

On-Line  Update 

The  terminal  processing  and  display  subfunction  shall  permit  on-line 
file  maintenance  when  required  via  terminal  request  or  when  required  by 
the  comnuni cation  processing  function  upon  input  of  new  data  for  the 
targeting/maneuver  application. 

The  on-line  update  component  shall  permit  translation  of  externally 
used  data  values  to  coded  data  base  values  as  required.  The  translation 
function  shall  consist  of  an  expandable  argument/function  dictionary. 

Upon  input,  the  argument  is  the  user  or  external  system  input  name  for 
the  data  element  and  the  function  substituted  for  this  in  the  data  base 
is  the  internally  coded  data  element  form.  Often  multiple  user  names 
look  up  the  same  coded  form.  A  separate  table  can  be  used  by  the  output 
process  modules  to  take  the  internally  coded  form  as  the  argument  and 
look  up  the  user  or  external  system  output  form.  User  or  external  system 
input  values  do  not  have  to  equal  output  values. 

The  on-line  update  shall  automatically  perform  inference  processing 
as  required  on  all  input  data.  Inference  processing  is  the  logic  through 
which  selected  data  elements  within  an  incoming  message  can  be  inferred 
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dependent  upon  the  content  of  one  or  more  other  data  elements  of  the 
same  incoming  message.  When  not  reported,  inference  processing  snail 
attempt  to  infer  values  for  the  following  target  parameters  as  a 
minimum: 


Target  Category 
Target  Worth 
Method  of  Detection 
Target  Permanence 
Target  Location  Error 

Appendix  III  indicates  a  representative  inference  table/rule  set.  It 
shall  be  possible  to  extend  inference  processing  to  more  data  base 
fields  than  those  indicated  as  well  as  change  the  inference  rules. 

On-line  update  shall  be  accomplished  by  means  of  executing  a 
precompiled  file  maintenance  logic  statement  against  an  update  trans¬ 
action  entered  either  by  an  operator  or  the  communication  processing 
function.  The  input  transaction  is  validated  by  the  logic  statement 
during  execution,  if  errors  are  detected,  immediate  notification  will 
be  given  to  a  control  terminal  operator. 

Edit 


The  edit  capabilities  within  the  terminal  processing  and  display 
subfunction  shall  permit  on-line  creation,  modification  and  management 
of  source  program  statements.  From  the  on-line  terminal,  it  shall  be 
possible  to  have  source  programs  error-scanned  by  the  component  syntax 
validation  routines,  corrected,  and  submitted  to  the  operating  system, 
for  background  execution.  The  user  shall  also  be  able  to  write  or  modify 
a  program,  have  its  language  and  format  verified  by  the  appropriate  data 
base  management  software  component  make  any  recommended  corrections,  and 
submit  the  job  for  background  execution  from  the  terminal. 
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On-Line  Utilities 


Utility  functions  shall  be  provided  to:  (1)  enable  the  user  to 
display  the  current  contents  of  the  input  message  queue;  (2)  transfer  a 
message  from  the  display  station  to  the  computer  operator;  (3)  transfer 
data  sets  between  terminal  stations.  (Thus,  a  set  of  qualified  records 
produced  as  a  result  of  an  interrogation  may  be  reviewed  by  other 
terminal  users  if  the  originator  so  chooses.) 

3. 2. 2. 5  Output  Processor 

This  component  shall  permit  flexible  formatting  of  qualified  data 
for  output.  It  shall  contain,  in  addition  to  normal  page  formatting 
capabilities,  capabilities  for: 

complete  logical  conditioning  of  the  data 
computation 

summarizations ,  totaling  and  subtotaling 
one  and  two  dimensional  sum  and  count  matrices 
comprehensive  report  generation  capabilities 

3. 2. 2. 6  Utilities 

This  component  shall  provide  as  a  minimum: 

complete  data  validation/conversion  table  generation 
capabi 1 i ties 

facilities  for  subroutine  generation,  checking,  and  loading 
(with  proper  linkage  for  use  by  all  desired  data  management 
function  modules ) . 
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3.2.3  Graphics  r.v.essing  Software  Functions 

3.2. 3.1  Introduction 

Software  functions  for  supporting  DIVRAS  graphics  processing  are 
described  in  the  following  paragraphs.  Tne  intent  is  to  describe 
representative  functions  but  not  indicate  that  any  one  or  group  of 
functions  be  performed  in  a  specific  way  by  a  specific  programming 
routine.  Any  software  design  approach  which  allows  equally  convenient 
and  effective  performance  of  these  functions  shall  satisfy  these  require¬ 
ments.  The  functions  are  described  in  two  categories: 

Applications  -  Applications  dependent  functions  are  those  designed 
expressly  for  the  DIVRAS  targeting  and  maneuver 
applications . 

Graphics  Support  -  Applications  independent  functions  are  those 
providing  the  functions  of  image  management  and 
image  generation  which  are  basic  to  the  digital 
display  capability. 

An  overview  functional  diagram  of  these  elements  is  presented  in 
Figure  3.2. 3-1 . 

3.2. 3.2  Interactive  Controls 

Interactive  devices  of  the  types  enumerated  below  shall  provide  for 
user  coitmuni  cation  with  displays.  Graphics  software  functions  shall 
provide  the  appropriate  responses  when  activated  by  these  or  equivalent 
devices . 
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Function  Keyboard 

Function  keys  shall  be  used  to  start  and  terminate  functions  and 
routines.  Each  function  key  shall  be  reprogrammable  by  a  computer 
progrannier  with  sufficient  skill  and  experience  to  understand  the  basic 
software  system.  Each  function  key  shall  indicate  when  the  function  it 
controls  is  being  used  by  lighting,  changing  color,  or  by  some  other 
equally  visible  technique. 

Software  for  translating  function  key  codes  shall  be  designed  to 
support  at  least  40  separate  function  keys  and  at  least  300  individual 
function  codes  assuming  that  a  hierarchical  control  tree  structure  is 
employed. 

Trackball/Cursor 


A  trackball /cursor  combination  (or  equivalent  control)  shall  be 
used  in  conjunction  with  the  function  keys  and  other  interactive  controls 
to  move  symbols,  to  draw  lines,  and  to  perform  other  functions  that 
require  positioning  of  a  point  or  symbol  on  the  display  screen.  The 
cursor,  in  a  crosshair  shape,  shall  be  provided  to  allow  the  operator 
to  sense  location  and  movement  on  the  screen  in  response  to  commands 
from  the  trackball.  The  system  shall  be  designed  so  that  upon  request 
made  by  function  key,  the  Military  Grid  Reference  (MGR)  coordinates  of 
the  cursor  location  are  displayed  either  under  the  cursor  or  at  some 
previously  designated  standard  position  on  the  screen. 

Alphanumeric  Character  Set  Controls 

Suitable  key  functions  shall  be  provided  for  displaying  the  full 
set  of  64  ASCII  characters.  Supporting  software  shall  be  capable  of 
interfacing  with  a  standard  typewriter  keyboard  configuration  or 
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interfacing  with  the  equivalent  functions  implemented  as  a  part  of  the 
function  key  hierarchical  control  tree  structure. 


Blink 


The  system  shall  be  designed  so  that  any  character,  symbol,  or 
group  of  symbols  and/or  characters  may  be  caused  to  blink  on  and  off  to 
call  the  blinking  symbols  to  the  attention  of  the  console  operator.  The 
system  shall  be  designed  so  as  to  start  and  stop  blinking  either  by  soft¬ 
ware  command  as  a  part  of  the  software  routine  or  as  a  result  of  depress¬ 
ing  a  function  key  and  then  picking  a  symbol  with  the  cursor  or  other 
control  device. 

3. 2. 3. 3  Applications  Software 

The  software  functions  making  up  the  applications  program  package 
are  described  below  in  the  following  categories: 

Control  Program 

Automatic  Graphics  Data  Generator 
Data  Base  Interface  Subroutines 
Function  Key  Translator 
Operator  Action  Subroutines 

3.2. 3. 3.1  Control  Program 

The  control  program  function  shall  handle  external  interrupt  cointiu- 
nications,  the  engagement/disengagement  of  the  several  application  routines 
and  the  graphics  processing  initialization/table  load  functions.  It  shall 
operate  in  an  asynchronous  mode.  Interrupts  will  be  queued  and  handled 
in  accordance  with  predefined  priority  rules.  This  program  shall  gain 
control  of  operations  whenever  all  outstanding  requests  are  completed. 
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At  such  time  the  control  function  enters  the  wait  state  until  the  next 
request  for  service  is  posted. 

During  initialization  the  system  responds  directly  to  operator 
comnuni cation  either  via  the  card  reader  or  via  the  function  keyboard. 
The  objective  is  to  assemble  those  files,  tables  and  load  modules  which 
satisfy  the  machine  configuration,  the  connected  display  terminals,  and 
the  graphics  performance  requirements. 

3. 2. 3. 3. 2  Automatic  Graphics  Data  Generator 

This  function  shall  provide  the  capability  to  automatically  process 
data  base  information  received  from  the  interface  subroutines  into 
instructions  and  data  suitable  for  transfer  to  the  graphics  data  output 
area  and  subsequent  image  generation.  In  the  case  of  target  of  interest 
data  processing,  the  function  is  triggered  by  the  target  analysis 
algorithm  and  needs  no  operator  initiated  ac*'ir  I n  the  case  of 
maneuvers  data  processing,  the  function  is  triggered  by  an  operator 
initiated  query  to  the  data  base  subsystem. 

Target  of  Interest  DaJLa  jyroces_s  ijn£ 

This  subfunction  shall  be  triggered  any  time  the  DIVRAS  Target  of 
Interest  function  (see  Section  3.1)  makes  a  decision  to  display  a  new 
target  message  and  its  associated  graphic.  When  triggered  the  sub¬ 
function,  using  message  data  supplied  to  it  by  the  data  base  interface 
subroutine,  shall  automatically  assemble  the  graphic  instructions/data 
needed  to  build  the  target  picture  (target  symbol  type,  color  and 
location)  and  cause  these  to  be  transferred  to  the  Graphics  Data  Output 
Area  whicti  services  the  Targeting  Display. 
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Situation  Graphics  Data  Processing 

This  subfunction  shall  be  triggered  upon  receipt  of  Unit  Situation 
Display  related  data  base  information.  When  triggered  the  subfuncti on , 
using  extracts  from  the  ENSIT  and  FRENSIT  data  supplied  to  it  by  the 
data  base  interface  subroutine,  shall  automatically  assemble  the  graphic 
instructions/data  needed  to  build  all  requested  symbols  (unit  type,  color, 
echelon,  numeric  label  and  location).  These  shall  be  transferred  to  the 
Graphics  Data  Output  Area  which  services  the  Maneuvers  Display. 

Shooter,  Mover,  Emitter  Graphics  Data  Processing 

This  subfunction  shall  be  triggered  upon  receipt  of  Shooter,  Mover, 
and  Emitter  r  lated  data  base  information.  When  triggered  the  subfunction, 
using  S/M/E  location  message  information  supplied  to  it  by  the  data  base 
interface  subroutine  or  by  direct  access  to  a  data  set,  shall  automatically 
assemble  the  graphic  instructions/data  needed  to  build  all  requested 
shooters,  movers  and  emitters  (type,  location,  quantity)  and  cause  this 
to  be  transferred  to  the  Graphics  Data  Output  Area  which  services  the 
Maneuvers  Display. 

3. 2. 3. 3. 3  Data  Base  Interface  Subroutines 

The  data  base  interface  subroutines  listed  below  shall  handle 
exchange  of  information  between  the  graphics  processing  software  functions 
and  the  data  base  management  subsystem.  These  interface  subroutines  shall 
be  designed  to  accomplish  the  transfer  of  formatted  requests  (generated 
from  the  interpretation  of  function  key  codes)  into  the  terminal  monitor 
of  the  data  base  subsystem  and  to  receive  information  from  the  data  base 
subsystem,  causing  this  data  to  be  linked  back  to  the  requesting  terminal 
when  it  enters  the  graphics  processor  subsystem. 
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Interface  subroutine  shall  provide  f or  ■ 

•  Transfer  or  requests  to  the  data  base  for  Unit  Situation  data, 
specifying  time,  area  of  interest,  and  lowest  echelon  for 
display 

•  Transfer  of  Unit  Situation  graphics  related  data  from  the 
ENSIT  and  FRENSIT  fi'es  to  the  graphics  processing  subsystem 

•  Transfer  of  Target  of  Interest  graphics  related  data  from  the 
target  message  data  files  to  the  graphics  processing  subsystem 

•  Transfer  of  requests  to  the  data  base  for  Shooter,  Mover  and 
Emitter  data  specifying  time  and  area  of  interest  for  display 

•  Transfer  of  Shooter,  Mover  and  Emitter  graphics  related  data 
from  the  data  base  adjunct  files  to  the  graphics  processing 
subsystem 

•  Transfer  to  the  data  base  management  subsystem  of  MGR  coordi¬ 
nates  of  a  cursor  identified  symbol  or  other  graphic  feature 
with  link  to  associated  query  message 

•  Transfer  to  the  data  base  of  trackball  generated  polygon 
shape  with  link  to  associated  control  area  message 

•  Transfer  to  the  data  base  of  completed  threat  frames  with 
identifier  number  and  time  stamp 

•  Transfer  of  stored  threat  frame  data  from  the  data  base 
maneuver  files  to  the  graphics  processing  subsystem. 
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3. 2. 3. 3.4  Function  Key  Translator 


The  Function  Key  Translator  subroutines  shall  be  designed  to 
service  all  manual  inputs  received  through  the  graphics  display  function 
keys.  The  subroutines  shall  interpret  the  key  codes  and  shall  invoke 
the  appropriate  operator  action  subroutines  thereby  enabling  and  causing 
execution  of  instructions  for  the  display,  manipulation,  storage  and 
recall  of  graphics  data  as  selected  by  the  display  operator's  actions 
(see  section  below  for  list  of  operator  actions). 

3.2. 3. 3. 5  Operator  Action  Subroutines 

The  functions  enumerated  in  this  section  are  those  that  accomplish 
processing  in  response  to  operator  instructions  and  data  entered  through 
the  function  keys  and  trackball/cursor.  They  are  the  routines  that 
allow  the  user  to  build  and  manipulate  symbols  and  free  draw  graphics, 
call  and  remove  scene  data  and  overlays,  enter  queries  into  the  system 
via  the  graphic  display  console,  etc. 

These  are  described  below  in  terms  of  the  function  capabilities 
inherent  in  the  keyboard  and  trackbal 1 /cursor  controls. 

SYMBOL  CONTROLS 


Select  Symbol  Type 

When  this  function  is  actuated  a  subroutine  shall  cause  a  menu  of 
symbol  types  to  be  presented  and  shall  interpret  the  type  selected 
to  the  system. 
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Build  Symbol 

This  function  is  always  actuated  with  selection  of  type.  As  a 
function  of  type  ^elected,  the  BUILD  SYMBOL  function  will  invoke 
the  appropriate  subroutine  to  create  a  new  symbol  in  the  graphic 
display  output  area  of  the  graphics  processor  and  simultaneously 
on  the  display  screen. 

If  symbol  type  selected  is  a  standard  military  flag  (rectangle) 
the  software  function  shall  compose  this  from  multiple  elements 
in  the  standard  symbol  library.  A  different  software  function 
shall  be  invoked  to  compose  large  military  graphic  symbols  such 
as  a  minefield,  area  receiving  artillery  fire,  etc.  Still  a 
different  software  function  shall  be  invoked  to  compose  vector 
(threat)  symbols  which  are  formed  by  a  series  of  line  vectors  in 
a  specified  arrangement  and  size. 

Another  software  function  shall  be  invoked  to  permit  rotation  of 
the  vector  symbols  during  build.  Placement  on  the  screen  shall  be 
accomplished  either  by  fixing  the  symbol  origin  via  trackbal 1 /cursor 
control  or  via  entry  of  MGR  data  through  the  function  keys.  Soft¬ 
ware  function  design  shall  allow  accuracy  of  placement  to  within 
+_  150  meters  with  respect  to  map  background  at  a  scale  of  1:50,000. 
The  accuracy  of  orienting  vector  symbols  shall  allow  rotation  to 
within  +5°  of  the  cursor-identified  orientation. 

Move  Symbol 

When  this  function  is  actuated,  a  subroutine  will  oe  enabled  to 
move  the  cursor- identi fied  symbol  oriain  to  a  new  screen  location. 

The  symbol  and  all  amplifying  data  shall  move  as  a  group  to  a  new 
screen  location  as  identified  by  tne  cursor  position.  This  sub¬ 
routine  will  also  allow  repositioning  of  the  symbol  to  a  new  location 
in  response  to  coordinates  entered  through  the  function  keyboard. 
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Decl utter 


When  this  function  is  actuated,  a  subroutine  will  be  enabled  to 
move  the  symbol  flag  (keeping  the  symbol  origin  fixed)  to  a  new 
screen  location  to  allow  decl uttering .  The  flag  and  all  amplifying 
data  shall  move  as  a  group  to  a  new  screen  location  as  identified 
by  the  cursor  position.  This  subroutine  shall  allow  bending  of 
the  staff  between  flag  and  origin,  placement  of  the  inflection 
point  being  fixed  by  the  cursor  location  marked  by  the  operator. 

Label 


When  this  function  is  actuated  a  subroutine  will  be  enabled  to 
allow  labeling  (applied  for  the  first  time  or  modified)  of  a 
standard  military  unit  flag. 

Suppress 

Wnen  this  function  is  actuated  a  subroutine  will  be  enabled  to 
allow  the  temporary  removal  of  a  symbol  from  the  display  screen. 
The  symbol  so  identified  is  suppressed  but  not  removed  from  the 
graphic  data  output  area  of  memory.  A  symbol  suppressed  in  this 
manner  will  be  redisplayed  automatically  the  next  time  the  stored 
frame  is  called  up  for  display. 

Delete 


When  this  function  is  actuated,  a  subroutine  will  be  enabled  to 
cause  removal  of  a  cursor  identified  symbol  from  the  screen  and 
from  the  graphic  data  output  area. 
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Aggregate 

This  function  shall  provide  a  capability  to  collect  a  number  of 
unit  symbols  identified  by  cursor  action  for  aggregation  into  one 
vector  symbol.  This  function  will  cause  an  internal  table  to  be 
written  to  keep  track  of  the  unit  names  and  MGR  coordinates  associ¬ 
ated  with  a  vector  symbol.  The  function  will  also  provide  capability 
to  return  for  display  the  data  stored  for  each  unit  in  the  vector 
symbol . 

FREE  DRAW  GRAPHIC  CONTROLS 


Select  Line  Type 

When  this  function  is  actuated  a  subroutine  shall  cause  a  menu  to 
be  presented  and  shall  interpret  the  line  type  selected  (solid, 
dashed  or  dotted)  to  the  system. 

Draw  Line  Series 

When  this  function  is  actuated,  a  subroutine  shall  enable  the 
cursor  for  placement  of  successive  point  locations  which  the  system 
will  connect  with  straight  line  segments.  A  means  will  be  provided 
to  allow  termination  of  one  line  series  and  the  commencement  of  a 
new  line  series  in  either  the  same  or  a  different  line  type. 

Label  Line  Series 


When  this  function  is  actuated,  a  subroutine  shall  enable  the  cursor 
and  keyboard  for  entry  of  an  echelon  symbol  and  alphameric  data 
identifying  the  military  organization  numerals  on  either  side  of 
the  echelon  symbol. 
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FRAME  CONTROLS 


Select  Color 


When  this  function  is  actuated  the  subroutine  shall  cause  a  menu 
of  colors  to  be  presented  and  shall  interpret  the  color  selected 
to  the  system. 

Change  Symbol  Size 

When  this  function  is  actuated  a  subroutine  will  be  invoked  causing 
the  standard  military  symbols  on  the  display  (except  alphameric 
labels)  to  change  size. 

Expand 

Contract 


When  either  of  these  functions  is  actuated,  a  function  will  be 
invoked  causing  the  cursor  identified  location  to  become  a  new 
center  point  and  causing  the  screen  picture  to  be  appropriately 
repainted  to  the  operator-specified  scale.  This  subroutine  shall 
handle  the  functions  required  to  perform  off-centering,  expansion, 
contraction  and  scissoring  of  screen  images.  Off-centering  shall 
allow  selection  by  cursor  of  a  new  geographic  center  for  an  area 
to  be  enlarged.  Expansion  shall  provide  the  computations  necessary 
to  rescale  all  symbol  positions  and  line  graphics  which  still  appear 
in  the  enlarged  image  area.  Scissoring  shall  provide  for  cutting 
off  or  stopping  graphics  data  where  it  runs  off  the  edge  of  the 
display  screen. 
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The  contract  subroutine  shall  provide  for  rescaling  all  symbol 
positions  back  to  their  basic  or  XI  position.  This  subroutine 
shall  make  provisions  for  restoring  to  the  display  screen  any 
symbol  and  line  vector  data  that  was  cut  off  when  the  base  scene 
was  expanded. 

Save  Threat  Frame  (Temporary) 

Save  Threat  Frame  (Permanent) 

This  function  shall  provide  for  the  temporary  or  permanent 
storage  of  Threat  Frames  to  the  data  base  subsystem . 

Display  Order  of  Battle  Situation  Map 

This  function  shall  provide  for  call  up  from  the  data  base  of  Unit 
Situation  data  in  accord  with  operator  specified  input  parameters 
and  causing  the  display  of  this  data  on  the  graphics  screen. 

Display  Saved  Threat  JF rame 

This  function  shall  provide  for  calling  from  the  data  base  of  a 
previously  stored  Threat  Frame  and  causing  the  display  of  this 
data  on  the  graphics  screen.  Call  up  shall  be  by  frame  identifier 
number  or  by  time  tag. 

Advance  Threat  Frame 


This  function  when  actuated  shall  cause  advance  of  the  display 
picture  from  the  Threat  Frame  on  the  screen  to  the  next  Threat 
Frame  in  time  sequence. 


Reset 


This  function  when  actuated  shall  cause  the  screen  to  be  cleared 
of  all  image  information  and  cause  all  graphic  data  output  areas 
and  buffers  in  the  graphics  processor  to  be  reset  to  zero. 

Call/Suppress  Shooters  Element 
Call /Suppress  Movers  Element 
Call /Suppress  Emitters  Element 
Cal  1/Suppress  Map  Background  Element 

The  subroutines  handling  these  functions  shall  operate  in  a  flip- 
flop  fashion.  When  the  function  is  first  actuated,  the  element 
will  be  displayed  on  the  screen,  superimposed  on  any  elements 
already  present.  When  the  function  is  actuated  a  second  time, 
the  element  will  be  suppressed  from  the  screen  leaving  on  the 
screen  any  elements  previously  present. 

Cal  1 /Suppress  Threat  Frame 

This  function  shall  be  handled  in  flip-flop  fashion  but  in  reverse 
from  those  described  above.  When  the  function  is  first  actuated, 
the  threat  element  presently  on  the  screen  will  be  suppressed 
leaving  on  the  screen  any  other  elements  displayed.  When  the 
function  is  actuated  a  second  time,  the  threat  element  will  be 
redisplayed,  superimposed  on  any  elements  already  present. 

Measure  Distance 


When  this  function  is  actuated,  a  subroutine  shall  be  enabled  to 
read  successive  cursor  locations  and  compute  the  straight  line 
distance  between  points  in  kilometers  to  an  accuracy  of  +  300 
meters  with  respect  to  map  background  at  a  scale  of  1:50,000. 
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Display  MGR  Coordinates 


When  this  function  is  actuated  a  function  will  be  invoked  to 
convert  screen  coordinates  to  MGR  coordinates  and  the  MGR  coordi¬ 
nates  of  the  cursor  identified  point  will  be  displayed  in  a 
predefined  screen  area. 

Transfer  Coordinate  Location  Data 


When  this  function  is  actuated  a  subroutine  will  be  enabled  to 
read  the  cursor  location,  convert  to  MGR  coordinates,  and  transfer 
this  coordinate  data  to  the  data  base  subsystem.  This  function  is 
used  in  conjunction  with  transfer  of  a  query  message  (via  alpha¬ 
meric  termina’)  to  the  data  base  subsystem  whenever  the  query 
requires  identification  (to  the  data  base)  of  a  specific  symbol 
or  other  graphic  location. 

3.2. 3.4  Graphics  Support  Software 

DIVRAS  graphics  processing  shall  incorporate  the  following  basic 
software  support  packages: 

•  Image  management  and  image  generation  routines  that  allow  the 
application  programmer  to  work  with  the  graphics  processor 
without  requiring  him  to  have  intimate  knowledge  of  the  display 
hardware  or  the  data  formats  required  by  the  hardware. 

t  An  I/O  support  package  that  simplifies  the  programming  inter¬ 
faces  between  the  display  controller,  the  host  computer  and 
the  data  produced  by  the  image  management  and  image  generation 
routines . 
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The  capabilities  to  be  provided  in  these  support  packages  are 
described  below.  The  intent  in  these  paragraphs  s  to  describe  standard 
routines  that  in  large  measure  are  coimon  to  many  commercially  available 
graphics  display  software  packages.  Any  set  providing  equivalent  func¬ 
tion  would  be  satisfactory. 

Support  Software  Overview 

The  software  support  packages  shall  utilize  a  library  of  subroutines 
to  execute  the  functions  of  image  management  and  image  generation.  The 
primary  objective  of  these  subroutines  shall  be  to  facilitate  the  design 
of  application  programs  which  need  not  repetitively  incorporate  the  code 
for  formatting  and  managing  display  elements.  All  the  subroutines  shall 
have  standard  linkages  and  shall  be  callable  either  from  assembly  langu¬ 
age  or  compiler  language  programs  with  standard  call  statements.  The 
routines  shall  be  table  oriented  and  by  collecting  together  common 
parameters,  shall  simplify  the  communi cation  between  routines  and  reduce 
the  amount  of  core  storage  required  for  parameters. 

The  main  tables  shall  include: 

Graphic  Display  Output  Area.  This  buffer  contains  the  data  to  be 
displayed. 

Output  Area  Control  Block.  This  block  of  storage  is  set  aside  as 
a  central  information  source  containing  pointers  to  necessary  data 
blocks  and  pointers. 

Element  Correlation  Control  Block.  This  block  of  storage  contains 
the  names  and  pointers  to  all  the  elements  of  data  stored  in  the 
graphic  display  output  area. 
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Subroutine  Parameter  Table.  This  table  contains  information 
required  by  image  generation  routines  to  locate  and  process  the 
user  data. 

Screen  Parameter  Table.  This  table  defines  the  graphic  display 
resolution  and  portion  of  the  display  area  the  user  wishes  to  use. 

The  design  shall  be  such  that  the  storage  areas  for  these  tables 
shall  be  established  by  controls  carried  in  the  application  oriented 
programs;  routines  shall  be  available  for  initializing  these  tables. 

Graphic  Data  Organization 

The  graphic  data  created  in  the  graphics  processing  subsystem  shall 
be  generally  organized  into  segments  called  elements.  These  segments  or 
subdivisions  shall  be  arbitrarily  assignable  and  shall  be  addressable 
individually  without  involving  the  portions  of  the  display  which  are 
outside  the  element's  range.  Provision  shall  be  made  to  permit  elements 
to  be  embedded  within  elements.  The  design  shall  permit  nesting  of 
subelements  to  at  least  6  levels. 

Image  Management 

Image  management  routines  shall  be  designed  to  serve  three  purposes. 
First,  they  shall  be  used  to  set  up  tables  which  serve  as  conriuni cation 
links  between  the  elements  and  the  output  routines.  Second,  they  shall 
be  used  to  generate  elements  and  subelements  by  setting  up  an  index  to 
the  area  in  which  graphic  data  is  stored  and  provide  such  functions  as 
name  maintenance  and  level  search.  Third,  the  image  management  routines 
shall  provide  the  user  with  the  ability  to  modify  and  delete  elements 
that  have  previously  been  generated. 
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The  subroutines  that  shall  comprise  the  basic  image  management 
support  capability  shall  include  functions  of  the  types  itemized  below: 

•  Initialize  output  area  control  block 

•  Begin  element;  assign  element  name  in  element  correlation 
control  block 

•  End  element 

•  Suppress  element  from  screen 

•  Restore  element  to  screen 

•  Compress  data  in  the  graphics  data  output  area  and  element 
correlation  control  block 

•  Add  element 

•  Replace  element 

•  Reallocate  space  for  either  the  graphics  data  output  area 

or  element  correlation  control  block 

t  Change  element  name 

•  Locate  element  name  in  control  block  hierarchy. 

Image  Generation 

The  image  generation  subroutines  shall  be  used  to  create  appropriate 
control  words  to  be  used  in  requests  for  the  display  of  individual  char¬ 
acters,  lines  of  characters,  individual  vectors,  and  connecting  vectors. 
It  shall  be  the  function  of  the  image  generation  subroutines  to  take  data 
supplied  by  the  user  and  interpreted  in  the  application  programs  and 
place  it  in  a  format  that  will  be  accepted  by  the  system. 

Tables  generated  by  the  application  routines  serve  to  pass  param¬ 
eters  to  the  image  generation  routines.  The  routines  shall  search  these 
tables  for  indication  as  to  what  is  to  be  done  with  the  data  and  for 
addresses  of  other  tables  necessary  in  subsequent  processing. 


3-119 


The  subroutines  that  shall  comprise  the  basic  imaye  generation 
support  capability  shall  include  functions  of  the  types  itemized  below: 

•  Initialize  subroutine  parameter  table.  Store  location  of 
the  output  area  control  block  and  screen  parameter  table. 

•  Store  text  and  coordinate  information  in  trie  suL-outine 
parameter  table 

•  Store  parameters  for  character  and  line  spacings  in  the 
s-ubrou-tine  parameter  table 

•  Store  values  for  indexing  through  the  X  and  Y  arrays  (of  the 
graphics  data  output  area)  in  the  subroutine  parameter  table 

•  Initialize  screen  parameter  table.  Define  portion  of  the 
graphic  display  area  to  be  used  if  an  expansion  or  contraction 
of  the  screen  image  is  called  for. 

•  Compute  and  store  scissoring  parameters  to  control  the 
rescaling  of  symbol  screen  positions  for  an  expansion  or 
contraction  of  the  screen  image. 

•  Store  orders  (instructions)  for  display  of  individual 
characters . 

•  Store  order  for  display  of  a  string  of  cnaracters 

•  Generate  vectors  for  pairs  of  coordinates.  Control  order 
in  which  segments  are  connected. 
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Input/Output  Support 


The  input/output  subroutines  shall  be  designed  to  control  the 
interchange  of  instructions  and  data  between  the  display  controller 
and  the  nost  computer.  The  subroutines  comprising  this  package  snail 
include  functions  of  the  types  itemized  below: 

•  Initialize  a  write  command  table  containing  a  channel  command 
word  for  each  element  in  the  graphic  data  output  area. 

•  Transfer  graphic  information  in  the  graphic  data  output  area 
to  the  display  terminal  to  replace  previous  contents  of  the 
display  refresh  buffer. 

«  Transfer  partial  graphic  information  in  the  graphic  data 
output  area  to  the  display  to  be  added  to  tne  contents  of 
the  refresh  buffer. 

t  Transfer  graphic  information  in  the  graphic  data  output  area 
to  the  display  to  be  deleted  from  the  refresh  buffer  associ¬ 
ated  with  a  particular  display. 

•  Specify  to  the  application  routine  the  current  position  of 
the  operator-control  led  cursor. 

•  Enable  keyboards  at  specified  terminals  and  associate  them 
with  the  user's  task.  Enable  presentation  of  displays. 

•  Place  program  in  wait  state  until  specific  inf  rrupt(s)  have 
been  received  or  tne  I/O  is  complete. 

•  Disable  keyboards  at  specified  terminals  and  terminate  displays 
there. 
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t  Perform  selected  display  control  functions  at  a  specified 
terminal  such  as  setting  a  program  function  keyboard 
indicator. 
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3.3  SYSTEM  PERFORMANCE/CAPACITY  REQUIREMENTS 


3.3.1  General  Environment 

The  organizational/operational  environment  for  deployment  of  the 
OIVRAS  application  areas  shall  be  in  accordance  with  current  U.  S.  Army 
policies  and  doctrine  for  fieldable  Division-Level  tactical  command  and 
control  systems  as  represented  by  the  Division  Tactical  Operations 
System  (TOS). 

3.3.2  System  Performance  Parameters 

The  following  response  times,  processing  times  and  accuracies 
shall  be  required  for  effective  implementation  of  the  DIVRAS  applica¬ 
tions  outlined  in  Section  3.1.  Unless  otherwise  stated,  all  response 
time  requirements  shall  be  met  or  bettered  at  least  80  percent  of  the 
time. 

3. 3.2.1  Response  Times  at  Terminals* 

General  query  requirements  [Local  Query] 

a.  Response  to  simple  query  requiring  4  seconds 

retrieval  of  single  record 

b.  Response  to  query  requiring  search  of  10  seconds 

data  base  to  qualify  n  records  (without 
summarization) 


*NQTE:  Response  time  =  system  processing  time  (not  operator  actions) 
and  is  measured  from  time  of  final  operator  action  to  initiate  process 
until  result  is  on  display  screen. 


3-123 


c. 


2(J  seconds 


Response  to  query  requiring  search  of 
data  base,  qualification  of  n  records, 
and  processing  for  display  in  specified 
output  format. 

Specified  query  requirements  [Local  Query] 


a. 

Call  stored  menu/operator  aid 

2 

seconds 

b. 

Call  stored  query  format 

2 

seconds 

c. 

Call  data  about  cursor-identified 

symbol  (from  the  already  qualified 
data  set  being  displayed) 

4 

seconds 

Input 

Processing  Requirements 

General 

a.  The  OIVRAS  targeting  application  shall  be  capable  of 
accepting  and  processing  targeting  application  messages 
at  a  peak  rate  of  10  per  minute. 

b.  Concurrently,  the  DIVRAS  maneuver  application  shall  be 
capable  of  processing  received  location  data  and  auto¬ 
matically  updating  display  buffers  once  every  b  minutes. 

The  processing  above  shall  be  concurrent  with  normal  operator/ 
analyst  terminal  interactions  on  either  of  two  terminals  to  control, 
display,  query,  and  utilize  the  input  information. 
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Target  Messages 


a.  Targeting  messages  shall  be  taken  out  of  the  communications 
processing  subsystem  queue  for  processing  by  the  application 
process  in  an  average  time  of  less  than  lb  seconds  after 
receipt  and  validation.  The  maximum  time  shall  not  exceed 
180  seconds. 

b.  Individual  targeting  messages  shall  be  processed  in  less 
than  30  seconds  from  the  time  application  processing 
begins  on  that  message  until  the  analyst  is  alerted. 

c.  Multiple  target  messages  shall  be  processable  concurrently . 
Shooter/Mover/Emitter  Location  Data 

Shooter/Mover/Emitter  location  data  shall  be  processed  and  made 
available  for  graphic  display  call-up  in  an  average  time  of  less 
than  30  seconds  from  the  time  the  data  is  received,  validated, 
and  processed  in  the  time  blocked  queues  by  the  connuni cati ons 
processing  subfunction. 

3. 3.2. 3  Graphic  Interactions 


a. 

Call  Shooter,  or  Mover,  or  Emitter 

overl ay 

L 

seconds 

b. 

Call  stored  display  scene 

4 

seconds 

c. 

Store  displayed  scene 

4 

seconds 

d. 

Add/change/delete/move  i nteracti ve 

symbol 

2 

(per 

seconds 
operation ) 

e. 

Change  scale  of  graphic  display 

6 

seconds 

f. 

Create  Unit  Situation  Display  from 

FRENSIT  data 

ENS IT/ 

40 

seconds 
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3. 3.2.4  Accuracy/Resolution  Requirements 

Accuracy  of  locating  a  point  on  display  screen  +150  meters 
with  cursor  at  1:50,000  scale  for  query  or 
symbol  placement. 
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APPENDIX  I.  MESSAGE  FORMATS 


This  appendix  details  the  formats  indicated  for  all  message  types 
on  Figure  3. 1.1-4  of  paragraph  3.1.1.  The  circled  letter  of  each  format 
statement  or  description  contained  in  this  appendix  refers  to  that 
indicated  in  Figure  3. 1.1-4. 


©  This  format  represents  a  general  SOTAS  input  form  to  DIVRAS.  The 
elements  of  this  message  are  indicated  in  Figure  1-1  and  further 
identified  in  the  data  field  glossary  of  this  appendix.  In  certain 
instances,  such  as  certain  query  responses,  multiple  targets  are 
involved.  In  this  case  repetition  of  the  necessary  information 
elements  in  the  response  message  may  be  appropriate. 

©  This  format  represents  a  query  or  standing  information  request  for 
Division  SIGINT  Sources  or  a  query,  standing  track  request,  or 
specific  track  update  request  for  SOTAS.  The  elements  of  this 
message  are  indicated  in  Figure  12  ano  further  identified  in  the 
data  field  glossary  of  this  appendix. 


For  standing  requests  for  target  reporting,  it  is  implied  that  the 
DIVRAS  analyst  can  select  areafs),  target  type/characteristics  and 
quantity  thresholds.  The  time  interval  in  these  cases  represents 
the  length  of  time  the  analyst  wishes  this  standing  request  to  be 
outstanding.  (There  can  be  more  than  one  outstanding  at  any  one 
time.)  The  target  reference  number(s)  in  these  cases  is  unused 
and  the  Query/Request  number  identifies  this  request  as  a  standing 
request. 


For  query,  it  is  implied  that  similar  criteria  bound  the  query. 

In  these  cases,  the  time  interval  (DTG  and  span)  bound  the  historical 
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FIGURE  I  - 1 .  REPRESENTATIVE  SOTAS  TRACK  FORMAT 


window  for  the  query.  The  query/request  number  identifies  this  as 
a  query  and  further  is  included  in  the  response  message  for  re¬ 
linkage  with  the  query  in  DIVRAS.  Again  the  target  (track)  refer¬ 
ence  number  is  unused. 


For  a  specific  track  update  request,  the  query/request  number 
identifies  it  as  such.  The  target  (track)  reference  number(s) 
indicate  the  track(s)  on  which  update  is  requested.  The  time 
interval  is  the  future  time  span  during  which  periodic  update  is 
automatically  required.  The  remaining  fields  are  not  used. 


(^C^Thi 


This  format  represents  a  general  command  guidance  format  for  the 
SOTAS  and  Division  SIGINT  Sources.  The  elements  of  this  messaqe 
are  indicated  in  Figure  1-3  and  further  identified  in  the  data 
field  glossary  of  this  appendix. 


For  direct  reporting  command  guidance,  the  command  guidance  (DR  or 
GEOM)  field  so  indicates.  In  this  case  the  node  for  direct 
reporting,  the  criteria,  and  the  future  time  span  for  the  direct 
reporting  to  take  place  are  identified.  More  than  one  such  direct 
reporting  command  guidance  message  may  be  outstanding  at  any  one 


For  other  command  guidance  (namely  battlefield  situation/geometry 
descriptions  which  better  enhance  and  coordinate  the  sensor  ground 
station's  interpretation  of  received  data),  the  free  text  portion 
is  used  and  assumes  operator  interpretation  for  use  at  the  ground 
station  before  influencing  the  ground  station  system  operation. 


^D^Thi 


This  format  represents  a  general  photint/sigint  target  format  for 
reporting  analyzed  emitter/photo  target  data  to  DIVRAS  from 
Division  SIGINT  Sources  as  well  as  Corps  photointelligence  or 
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SIGINT  sources.  The  elements  reported  are  indicated  in  Figure  1-4 
and  are  further  identified  in  the  data  field  glossary  of  this 
appendix. 

©  This  format  represents  a  time  grouped  (bulk)  message  containing 
detected  target  locations  transmitted  periodically  to  DIVRAS  from 
Division  SIGINT  Sources,  CORPS  SIGINT  sources  and  TACFIRE. 

Figure  1-5  indicates  the  message  elements  of  the  bulk  message  which 
are  further  identified  in  the  data  field  glossary.  Each  line 
element  contains  a  simple  alpha  code  indicating  the  type  of 
location  the  line  element  identifies  the  coordinate  of  the  sighting 
and,  if  known  (as  is  possible  in  the  case  of  TACFIRE  shooter  or 
mover  location  data),  the  estimated  number  of  vehicles  or  shooters. 


These  formats  are  the  existing  TACFIRE  formats  as  defined  for  that 
system. 


These  formats  are  the  existing  TOS  Operable  Segment  formats  as 
defined  for  that  concept  validation  test  bed  system. 

DATA  FIELD  GLOSSARY 

The  data  fields  are  listed  in  the  sequence  they  are  encountered  in 
Figures  1-1  through  1-5. 

Message  Type  -  an  alphanumeric  code  that  identifies  the 
external  node  and  generic  class  of  information  contained 
in  the  message. 


REQUIRED  ON  ALL  QUERY  RESPONSES  FROM  DIVISION  SIGINT  (MESSAGE  TYPE  CAT ) 


I 
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REPRESENTATIVE  PHOTINT/SIGINT  TARGET  FORMAT 
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Query/Request  Number  -  a  message  numbering  used  for  uniquely 
matching  external  nodal  responses  and  D1VRAS  requests  for 
information. 

Target  Reference  (or  Track)  Number  -  a  numbering  system 
attached  to  a  target  or  track  by  its  originating  node  which 
uniquely  identifies  targets  originated  by  that  node  (i.e. 

QSTAG  221) . 

Event  Date/Time  -  the  date  and  time  of  the  event  being 
reported  (in  DTG  format). 

Direct  Report  -  indicates  that  the  message  has  been  directly 
reported  to  a  weapon  node  in  accordance  with  currently  out¬ 
standing  guidance  for  direct  reporting.  For  DIVRAS  purposes, 
it  will  be  data  based  as  target  data  but  not  processed  as  a 
target  of  possible  incoming  interest. 

Tvpe/Subject  -  subject  which  the  messaqe  is  about  or  identi¬ 
fication  of  a  target  type. 

Target  Category  -  a  group  or  class  of  tarqet  subjects. 

Location  -  specific  location,  in  military  qrid  reference  (MGR) 
coordinates,  of  subject  or  tarqet  type  being  reported. 

Direction  -  for  moving  targets,  it  indicates  the  direction  of 
movement  of  the  target  as  a  compass  bearing  (e.g.  SSW  -  south 
by  southwest) . 

Velocity  -  indicates  the  rate  of  movement  of  the  target  being 
reported  in  kilometers  per  hour. 
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Quantity  -  an  estimate  of  target  quantity  where  appropriate. 

Track  Origin  -  specific  location,  in  military  grid  reference 
(MGR)  coordinates,  at  which  a  moving  target  was  initially 
detected. 

Track  Destination  -  specific  location,  in  military  grid 
reference  (MGR)  coordinates,  at  which  a  moving  target  track 
is  estimated  to  be  heading. 

Area(s)  of  Interest  -  named  area(s)  or  specified  circle 
centers  and  radi i . 

Time  Interval  of  Interest  -  a  time  interval  which  can  identify 
historical  time  of  interest  for  a  query,  or  command  guidance, 
standing  request,  or  specific  track  request  effective  time 
span. 

Quantity  Threshold  of  Interest  -  criteria  threshold  for 
target  reporting. 

Command  Guidance  -  indicates  whether  the  message  is  concerned 
with  specifying  direct  reporting  instructions  or  describing 
battlefield  situation  geometry. 

Direct  Report  Node  -  specifies  the  weapon  node  to  whom  the 
sensor  node  is  instructed  to  report  specified  tarqets,  under 
this  guidance  message.  (More  than  one  such  command  guidance 
message  may  be  outstanding  at  on-'  time.) 


1-10 


Target  Characteristics  -  a  detail  characteristic  describing 
a  target  (a  hierarchical  level  of  target  description 
includes  category  -  type/subject  -  characteristic) . 


Enemy  Unit  Identi fication  -  a  name  or  description  to  identify 
a  specific  enemy  unit  (e.g.  64  Tank  Regiment)  where  possible. 

Location  Error  -  Circular  Error  Probability  (CEP)  in  the 
reported  target  location,  measured  in  meters. 

Type  Code  -  this  code  is  used  with  the  bulk  message  to 
identify  detections  as  shooters,  movers,  radars  or  radios. 
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APPENDIX  II.  FILE  FORMAT  TABLE/DATA  ELEMENT  DEFINITION 


This  appendix  describes  a  representative  file  format  table  for  a  two 
level  structured  record  containing  a  fixed  information  set  and  multiple 
periodic  information  sets  as  described  in  paragraph  3.2.2.  For  any  given 
periodic  set,  there  can  be  as  many  repetitions  as  desired.  This  feature 
permits  assignment  of  multiple  information  items  within  a  periodic 
category  of  a  record  (such  as  multiple  target  periodic  sets  associated 
with  an  enemy  unit  record  or  target  history  sets  associated  with  a  target 
record) . 

The  basic  file  format  table  (Table  1 1 - 1 )  embodies  the  definitions 
indicated  in  the  column  headings  of  the  table.  The  set  number  identifies 
the  fixed  or  periodic  set  format.  Those  included  in  this  table  are: 


Set  000 

- 

Fixed  Set  Data 

Set  001 

- 

Polygon  Coordinate  Information 

Set  002 

- 

Friendly/Enemy  Unit  Data 

Set  003 

- 

Target  Data 

Set  004 

- 

Friendly  Unit  Equipment  Data 

Set  005 

- 

Friendly  Unit  Personnel  Data 

Set  006 

- 

Friendly  Unit  Critical  Supply  Data 

Set  007 

- 

Remarks  Data 

The  field  size,  mode,  and  label  provide  the  data  element  definition. 
For  example,  each  repeated  polygon  periodic  set  would  contain  a  two 
(size)  alphanumeric  (mode)  character  coded  polygon  name  and  a  three  (size) 
alphanumeric  (mode)  character  area  type  definition.  The  polygons  them¬ 
selves  would  be  defined  by  a  string  of  up  to  eight  coordinate  fields  each 
containing  up  to  15  characters  for  definition  of  the  coordinate. 
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*  '  '1 

• 

... 

... 

- 

AL  >H A 

... 
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... 
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... 

... 

... 
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... 
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- 
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... 

... 

... 

AOWE 
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... 
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- 
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... 

... 

... 
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TABU  11-1.  [XAMPLl  Fill  FORMAT 
SHUT  4  OF  b 


a  t  r)/'.*ic> 

N*«* 

FTATfM'NT 

cot  taTo« 

F  1  Ft  ■> 
Slit 

v-r  c 

U^L 

s«  t  «r t  • 

N'J.  LOGIC 

MODE  INPUT 

SUiP'T 

OjJO.fT 

suoot 

inir 

N4M- 

»r  AP3N 

FIELD 

C  C  2 

—  * 

003 

- 

ALPHA 

... 

... 

... 

OF  ST  °  DV 

FIELD 

:;3 

003 

- 

ALPHA 

... 

... 

— 

A  1  POE  F 

rifto 

:c? 

— 

003 

- 

ALPHA 

... 

... 

... 

OPSfOV 

FIELD 

DC  3 

— 

003 

- 

ALPHA 

— - 

— 

— 

hVALUc 

FIELD 

C  C  1 

— 

003 

- 

ALOHA 

... 

... 

... 

TF'LAGl 

F  I  ELD 

jC  1 

... 

003 

- 

ALPHA 

— 

— 

— 

TELAG2 

FIELD 

c:  i 

003 

- 

ALPHA 

— 

— 

—  - 

Tf LAG J 

FIELD 

M 

— 

003 

- 

ALPHA 

— 

— 

— 

THA3A 

c  1  EL  0 

C  ?! 

... 

003 

- 

ALPHA 

— 

— 

— 

T  *  LAv#S 

f  1  ELD 

c  '  1 

003 

ALPHA 

EGUI  P 

F  I  ELD 

C  C  6 

C  TL 

004 

- 

*L°HA 

— 

... 

... 

‘•CiAVAlL 

rliLO 

C«3 

... 

004 

- 

NUMFO 

... 

... 

... 

r gaut« 

FIELD 

C  0  3 

... 

004 

- 

NUMF4 

... 

... 

... 

tot  i  •»' 

F  I  ELO 

C  1  1 

... 

004 

- 

ALPHA 

... 

... 

— 

C  MSG 

F  1  EL  D 

C  1  1 

— 

004 

“ 

ALPHA 

Lcf 

f  1  EL  C 

*  S*  A 

_ 

005 

_ 

NUMF  « 

— 

— 

--- 

NC3 

FIELD 

C 

... 

005 

- 
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— 

... 

... 

F*- 

F  I  f-  LD 

: :  s 

... 
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- 

NU**C  O 

... 

... 

... 

Of  F »UT H 

F  I  FLC 
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... 
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- 
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... 

... 

... 
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FIELD 
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... 

005 

- 
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... 

... 
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... 
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... 

... 

-- 
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... 

... 
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TABLE  Jl-1.  UAMPU  FILE  FORMAT 
SHEET  *>  OF  b 


*LO/GHP  SMTtMLKT  FIFL^  S^hC  SrT  “CT  ,  %t’JOC  INPUT  OUT-»‘JT  FD|  T  F  J  *  lT/CjM'IUP/VAP.S5  t  Th*  r  l  A  G  *•  maO«$ 


NAHt 

OPF  » A’0« 

SI  2 1 

OSt  NO. 

LOG  1C 

sue*’* 

SO*-** 

PFRAVAL 

rffLC 

OC  3 

-  006 

«U*t  f* 

COT  AVAL 

M6UC 

CC7 

-  006 

- 

VUAfP 

— 

... 

ST 

r  I6LO 

C*  l  1 

-  006 

- 

ALPHA 

... 

... 

S**SG 

r  iflo 

C  1 ) 

-  006 

. 

aloha 

_ 

_ 

u  T  |  M* 

f  1  **LC 

C  I  1 

C*L  007 

- 

ALPHA  - 

— 

.^sr. 

*  irco 

V  .  A 

-  007 

- 

alpha  --- 

... 

fiS 4«p< 

'  1  i  L  C 

C  72 

-  007 

- 
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— 
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APPENDIX  III.  INFERENCE  RULES 


The  DIVRAS  system  provides  the  functional  ability  to  infer  selected 
target  report  fields  from  the  data  contained  in  other  fields  of  the  same 
target  report.  Inference  processing  is  provided  for  the  key  target 
parameters  of: 

1.  Target  category 

2.  Target  worth 

3.  Method  of  detection 

4.  Target  permanence 

5.  Target  location  error 

Tables  1 1 1 - 1  through  1 1 1 -3  indicate  a  representati  ve  inference  rule 
set  for  the  first  three  above. 

For  target  category  each  incoming  report  can  pick  up  to  two  cate¬ 
gories  as  they  are  first  encountered  processing  on  the  stated  fields 
(columns)  in  a  sequential  top  down  manner. 

For  target  worth  the  maximum  worth  number  encountered  is  assigned 
after  processing  the  entire  list  from  top  to  bottom. 
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TABLE  III-l 


INFERENCE  -  TARGET  CATEGORY 


MSG 

FORMAT 

TYPE 

S02  ~ 
S04  _ 

DA4C 


TYPE 

(CONTAINS^ 


S03 

S05 

ASSEMBLY 
ASSEMBLY  AREA 
CP/C2 
CP 
C2 

MICROWAVE 
SUPPLY/CS 
SUPPLY  POINT 
HELIPAD 
CANNON 
ARTILLERY 
MORTAR 
HOWITZER 
SP  ARTY 
RL 
MRL 
BTRY 
ARTY 


TARGET 

TARGET  CATEGORY 

CHARACTERISTICS  (ENTER  UP  TO  2) 

"concentration 

_ „  (AS  WELL  AS  TRACK 

ORIGIN  ON  FIRST 
OCCURANCE  OF  TRACK) 
TRACK  LOSS 


ASSEMBLY  AREA 


CP/C2 


SUPPLY/CS 


ARTILLERY 
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TABLE  II I -1  (CONTINUED) 


MSG 

FORMAT 

TYPE 


jyp£  TARGET 

(CONTAINS)  CHARACTERISTICS 

MET  RADAR 

BREAD  BIN 
END  TRAY 

ROCKET/MISSILE 
ROCKET  LAUNCHER 
SSM 

FROG  LAUNCHER 
SAM 

SAM  RADAR 

FIRE  CAN 
FLAT  FACE 
THIN  SKIN 
STRAIGHT  FLUSH 
LONG  TRACK 
SA-6 
SA-9 

CFR 

GSR 

CF  RADAR 
GS  RADAR 

PORK  TROUGH 
SMALL  YAWN 


TARGET 
CATEGORY 
( FNTER  UP  TO  2) 

MET  RADAR 

ll 

U 

ROCKET/MISSILE 

ll 

ti 

li 

SAM  RADAR/SAM 


CF /GSR  RADAR 
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c 
o  s: 

LD  CC 

UJ1 

IT3 

-O 

O 

o 

o 

^t 

C\J 

C\J 

CXJ 

on 

m 

m 

*T 

M 
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<Z 
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on 
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LU 

33 
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H  Ct  2 
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O 
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Q-: 

o 

23 

LU 

LU 

LU 
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o 
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>- 

c 
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CL 
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G 
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G 
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03 
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C\J 
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LU 

LU 

CL 

Cl 
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<c 
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CL 

03 
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LU 

1 
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co 
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>- 
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<£ 
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CD 

O 

»— 
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TABLE  1 1 1-3.  INFERENCE  METHOD  OF  DETECTION 


MSG  METHOD  OF 

FORMAT  DETECTION 

TYPE  (UP  TO  2  ENTRIES) 


502 

503 

504 

505 

506 
DA4c 
C04a 
C05a 
C06a 
C07a 
CA2 
CA3 
CA5 
C04b 
C05b 
C07b 
CA4 
C06b 


MTIR 


PHOTINT 


COMINT/COMINT  DF 


ELINT 


in-n 


m 


APPENDIX  I  V_._  INPUT  MESSAGE  RATES 


Figure  IV- I  is  a  detailed  analysis  of  the  DIVRAS  message  input 
rates  from  each  communication  source  indicated  in  Section  3.1.1. 

It  categorizes  the  messages  (detections)  as  shooter,  mover  or  emitter 
and  identifies  the  sensor  source  supplying  the  data.  The  items 
marked  N.A.  (not  applicable)  mean  that  the  identified  communication 
line  does  not  support  that  application.  For  example,  the  Corps  Tarqet 
Team-DIVRAS  coimuni cation  line  does  not  support  the  maneuver  application 
but  does  support  the  targeting  application. 

For  both  the  maneuver  and  targeting  application,  the  columns  titled 
"Average  Detections  per  Hour",  "Detections  in  Highest  Volume  Hour",  and 
"Target  Reports  per  Highest  Volume  Hour"  summarize  the  message  and 
detection  rates  used  to  drive  the  DIVRAS  Experimentation  Scenario 
(see  DIVRAS  Final  Report,  Aug.  3,  1977).  In  these  scenarios,  a  mathe¬ 
matical  model  was  used  to  direct  the  friendly  surveillance  sensor 
systems  against  the  enemy  target  model  and  generate  the  target  messages 
and  detections. 

The  columns  labeled  "Peak  Load  Detections  per  Hour"  and  "Peak  Load 
Target  Reports  per  Hour"  have  been  determined  by  taking  the  detections 
and  reports  in  the  highest  volume  hour,  for  each  sensor  and  increasing 
them  by  33  per  cent. 

For  the  maneuver  application,  it  was  assumed  that  five  minutes  of 
detections  would  be  accumulated  at  each  node  and  then  sent  as  a  burst 
message  to  DIVRAS.  The  peak  load  detections  in  five  minutes  per  sensor 
was  therefor  determined  by  dividing  the  peak  load  detections  per  hour 
by  twelve. 


IV-1 


The  number  of  bytes  per  communication  line  was  determined  from 
the  message  length  defined  in  Figure  IV-2.  These  lengths  were,  in 
turn,  determined  from  the  message  formats  defined  in  Appendix  I. 


_ _ MANEUVER  APPLICATION  TARGETING  APPLICATION 

MESSAGE  MESSAGE  MESSAGE  MESSAGE 

COMMUNICATION  HEADER  LENGTH  HEADER  LENGTH 

LINE  IDENTIFICATION  CATEGORY  SENSOR  SOURCE  (BYTES)  (BYTES)  (BYTES)  (BYTES) 


3  f-ternal  message  length 


